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(57) Abstract: A service discovery mechanism may 
allow clients in a distributed computing environment 
to search for services. The service discovery mecha- 
nism may allow a client to request a capabiUty creden- 
tial from a service. In one embodiment, the client may 
present to the service a set of desired capabilities. The 
service may then respond with a capability credential 
that may convey to the client the rights to use the re- 
quested capabilities. A complete service advertisement 
may be needed to create a message endpoirit for access- 
ing the service. In an embodiment, the capability cre- 
dential may be used by a client to obtain a complete ad- 
vertisement for the requested capabilities. The capabil- 
ity credential may provide an additional level of secu- 
rity for the service provider. The capability credential 
that may be used to receive the complete advertisement 
may also be used to construct a message gate to com- 
municate with the service where the gate embeds the 
capability credential in each message to the service. 
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BACKGROUND OF THE INVENTION 



1 Field of the Invention 

m invention relates to distn^uted computing enviroimients incluto^ 

distributed computing environments, and more particularly to a heterogeneous distributed computing environment 
based upon a message passing model for connecting network cUents and services, and the discovery of services m 
10 suchanaivironment 

2. Description of the Related Art 

Intelligent devices are becoming increasingly common. Such devices range from smart appliances, 
penional digital assistants (PDAs), cell phones, lap top computm, desktop computers, workstations, mainfiames; 
15 even, super computer. Networks are also becoming an increasingly common way to mten=om»ect intelligent 
devices so that they maV communicate with one another. However, there'may be large differences m the computmg 
power and storage capabilities of various mtelligent devices. Devices with more limited capabilities may be refened 
to as small footprint devices or "dun" devices. Thin devices may not be able to participate in networks 
iriterconnecting more capable devices. However, it may still be desirable to mtercomiect a wi^^ 

20 types of intelligent devices. 

The desire to improve networking capabiUties is ever mcreasmg. Busmess networks are expanding to 
include direct interaction with suppliers and customers. Cellular phones, personal digital assistants and Internet- 
enabled computers are commonplace in both business and the home. Home networks are available for 
interconnecting audio/visual equipment such as televisions and stereo equipment to home computers, and other 
25 devices to control mtemgent systems such as security systems and temperature control the™^^^^ 

mediums such as cable and ASDL enable unproved services such as hitemet access video on demand, e-commerce. 
etc. Network systems are becommg pervasive. Even without a formal network, it is stiU desirable for mteUtgent 
devices to be able to communicate with each other and share resources. 

Currently, traditional networks are complex to set up. «q«nd and manage. For example, adding hardware 
30 or software to a network often require a netwoHc administrator to load drivers and configure systems. Making 
small changes to a network configuration may require that the entire network be brought down for a penoA In 
addition,certamintelBgentdevicesmaynotsuppoitthenecessa,yinteriacestocommm^^ 

What is needed is a shnple way to connect various types of intelligent devices to allow for communication 
and sharing of resources while avoidmg the interoperability and complex configuration problems existing in 
35 conventional networics. Various technologies exist for hnprovmg the addition of devices to a network. For 
example many modem I/O buses, such as the Universal Serial Bus. 1394 and PO. support plug and play or 
dynamic discovery protocols to simplify the addition of a new device on the bus. However, these solutions are 
limited to specific peripheral buses and are not suitable for general networks. 

A more recent technology. Jini from Smi Mcrosystems. Inc.. seeks to sunplify tiie connection and sharing 

40 of devices such asprinters and disk drives on a network. A device tirat incorporates Pmi may announce itself to the 
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network, may provide some detafls about its capabilities, and may inimediately become accessible tp other devices 
onthenetwork. Jini allows for distributed computing ^ere the capabilities of the various devices are shared on a 
network. The Jii.i technology seeks to enable users to share services and resources over a network. Another goal of 
the Jini technology is to provide users wito easy access to resources anywhere on the network while alloAving the 
network location of the user to change. Jini also seeks to simplify the task of buildmg, maintaining and altermg a 
network of devices, software and users. 

Jini requires that each Jini enabled device have a certain amount of memory and processing power. 
Typically a Jmi enabled device is equipped with a Java Virtual Machine (JVM), nius. Jini systems are Java 
technology centered. Java is a high level object oriented programming language developed by Sun Microsy^^ 
Inc. Java source code may be compaed into a format caUedbytecode, which may then be executed by a Ja^ 

Virtual Machine. 

Bytecode is compmer source code that is processed by a virtual machine, rather than the "real" c^^^ 
machine the hardware processor. The virtual machine converts generalized machine instruction (the bytecode) into 
specific machine instructions (instructions that the computer's processor will understand). Using a lang^aee that 
comes with a virtual machine for each platfonn, the source language statements may be compUed only once 

thenrunonanyplatformlhatsupportsthevirtualmaehine. The Java programming language is an example of such a 
language, and the Java Virtual Machine (JVM) is an example of a virtual machine platform that supports programs 
written in the Java programming language. 

Since Java Virtual Machmes may be provided for most computing platforms, Java and thus Jmi provide 
for a certain amount of platform independence. The Jini architecture leverages off the assmnption that the Java 
programming language is the implementation language for the components of the Jini system. The ability to 
dynamically download and run Java code is central to many features of the Jini architecture. 

The purpose of the Jini architerture is to federate groups of devices and software components into a smgle 
dynamic distributed system. A key concept within the Jini architecture is that of a service. A service is an entity 
25 ,hatcanbeusedbyaperso„,aprogram,oranotherservice.Twoexamplesofservicesareprintingadocm^^^ 

translating from one word processor format to another. Jini aUows the members of a Jini system to share access to 
services Services in a Jini system communicate with each other by using a service protocol which is a set of 
interfaces written m the Java progr^ng language. Services are found and resolved m a Jini system by a look-up 
service; A look-up service maps interfeces indicating the fimctionaUty provided by a service to sets of objects that 

30 implement the service. 

Descriptive entries may also be assodated with a service. Devices and appUcations use a process toaown as 

discovery to register with the Jini networic Once registered, the device or appHcation places itself in the look-up 
service The look-up service may store not only pomteis to these services on the netv^ork, but also may store the 
code for accessmg these services. For example, when a printer registers with the 1^^^^ 

driver and/or an interface to the driver into the look-up service. When a cUent wants to use the printer, the driver 
and driver interfece are downloaded fem the look-up service to the client This code mobility means that cUents 
can take advantage of services from the network wi&out pre-installing or loadmg driv^ 

Communication between services in a Jini system is accomplished usmg the Java Remote Method 
Mvocation (RMl). RMI is a Java programmmg language enabled extension to tmditional remote procedure call 
mechanisms. RMI aUows not only data to be passed from object to object around the Jini network, but M objects 
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including code as wen. ,ini systen« depend upon to ability to move code ™^ 

encapsulated as a Java object ^ 
Access to services in a Jini system is lease base4 A lease is a grant of guaranteed access over a to^^ 

leaseisnegotiatedbetweentheuseroftheserviceandtheprovideroftheserviceaspartoftheservicep^^^^^ A 
5 servicemayberequestedforsomeperiodandacoessmaybegrantedforsomepcriodpresumabty 
request period. Leases must be renewed for a service to remain part of the Jini system. 

Figure 1 illustrates the basic Jini technology stack. The Jini technology defines a distributed piogrammmg 
model 12 (supported by JavaSpaces. leases, and object templates). Object communication in Jini is based on an 
RMI layer 14 over a TCP/IP capable networking layer 16. 
10 Jini is a promising technology for simplifying distributed computing. However, for certam types of 

devices Jini may not be appropriate. The computing landscape is moving toward a distributed. Web-centric service 
and content model where the composition of client services and content changes n,pidly. Ihe client of the fature 
may be a companion type device that users take with them wherever they go. Such a device may be a combmaUon 
ofacellphoneandaPDAforexample. It would be desir^le for sudr devices to be able to communicate and share 
15 resources with devices that are more powerful, as wellas with thimier or less powerflil devices. 

m addition with the advent of the Intemet and resulting explosion of devices connected to the net, a 
distributed programming model designed to leverage this phenomenon is needed. An enabling technology 

that facilitates clients comiecting to services in a reliable and secure fashion. Various clients from thick to thm and 
services need to be connected over the Internet, con,orate Internets, or even within single computers. It is desirable 
20 to abstract the distance, latency and implementation from both clients and services. 

The key challenge for distributed computing technology is to be scalable from powerfal thick clients down 
to veiy thm clients such as embedded mobile devices. Cmrent distributed computing technologies, such as Jini, may 
not be scalable enough for the needs of all types of clients. Some devices, such as small footprint devices or 
embedded devices, may lack sufficient memory .sources and/or lack sufficient networidng bandwidfli to participate 
25 satisfactorily in current distributed computing technologies. THe low end of the client spectrum, includmg 
. embeddedmobaedevices.oftenhavelimitedorfixedcodeexec«tionenvironments. Thesedevicesal^ 

nnrtoal or no persistent storage capabilities. Most small, emb^ded mobile devices do not support a Java Virtual 
Machine Most code-capable small cUents nm native code only. In addition, most smaU devices have Kttle more 
>„ flash memory or battery backed RAM as their sole persistent storage media. The si« of the storage ^ often 
30 verysmallandsometimesread-onlyinnami..Furthermore.theaccesstimeofthistypeofstom^^ 
order of magnitude greater than hard disk access time in clients that are more power&l. 

Existing <^miection technologies, such as Jini, may not be as scalable as desiredbecause ^^^^ 
For example. Jini n^quires that aU participants support Java; however, many sman chents may not have to 
foraJavaVirtualMachine. Furthermore, due to its use of RMI. rmi requires that cheats be able to download code 
35 ■ and content Jini may augment the existing client platform by downloadmg new classes, which may pose security 
and size concerns for small devices such as embedded devices. Jmi works by clients and resources commumcatmg 
bypassing code and data. When a client activates a Jini service, the service may retmn its results to the chent. 
^ch may include a large amount of code or content In Jini, a client may caU a method and a large object may be 
„^ed and thus downloaded. The client may not have the resource to accept the returned object. In addition. 
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EJVD and Java itself require a lot of memoiy. Many small foot print devices may not have the resources to 

participate eflfectiveiy or at all in cuirent distributed computing technologies. 

Another concern wifli existing distributed computing tedmologies is that they often require certain levels of 

connection capability and protocols. For example, Jini assmnes the existence of a network of reasonable speed for 

comiecting computers and devices. Jini also requires devices to support TCP/IP network transport protocoL 

However, many smaUer devices may have limited comiectiou capabilities. SmaU devices may have high latency or 

low speed network connections and may not support TCP/IP. 

As mentioned above. Jini requires devices to support Java and thus include a Java Virtual Machine, vvhich 

requires a certain amount of processing and storage capabilities that might not be present for many small devices. 

) Tins also restricts the flexibility of Jini m that non-Java devices may not directly ^^^^ Since 
Jini requkes Java, it may be deemed a homogenous environment However, it is desirable to have a distributed 
computing facility for heterogeneous distributed computmg that scales from extremely small embedded devices 
through PDA's and ceU phones to laptops and beyond even to the most powerfiil computers. 

Other heterogeneous solutions exist, such as flie Common Object Request Broker Architecture (CORBA). 

15 CORBA is an architecture that enables program objects to communicate with one anoflier regardless of the 
programming language they were written in or what operating system they're nmning on. However, CORBA does 
not address all of the comiection issues that are addressed by Jini. In addition, CORBA suffers from similar 

scalability problems as Jini. 

Technology such as Jini and CORBA use a code-centric programnung model to define the mterfece 

20 between remote components. A code-<:enlric programming model defines programmatic inteifeces or API's for 
communication between remote cUents or components. The API's may be defined in a particular programming 
language. The API's must be agreed to by all software components to ensure proper intaoperability. Since all 
access to components is through fljese standards API's, the code that implements these API's must be present in the 
client platform. Tlie code may be statically linked into the platform or dynamicalty downloaded when needed, 

25 Many embedded or mobUe devices simply cannot accept code dynamically from a network due to the quality control 
issues involved as weU as the reliance on a single language and program execution envkonment Data-centric 
models, such as networking protocols, may avoid the dependence on moving code; however, such protocols are not 
rich enough to easily provide for distributed computing and they also lack the ease of programming with code and 

other programming features, such as type safety. 

Conventional distributed computing systems tely on the ability of a program executing on a first device to 

be able to remotely call a program on a second device and have the results returned to the first device. The Remote 
Procedure Call (RFC) is abasic mechanismforremotely calling a program or procedure. CORBA and Jini are boft 
based on the ability to remotely invoke program methods. Howevw, communicating by passing code or objects, 
sudi as m Jini or CORBA, may be somewhat complex. For example, as mentioned above, Jini uses the Java Ranote 
35 Method Invocation (RMI) to conmiunicate between services, to order for a client to move Java objects to 

remote locations, some means of serialization/deserialization is needed. Such current feciUties in the Java 
Development Kit (JDK) rely upon the reflection API to determine the content of a Java object, and ultimately that 
code must consult the Virtual Machine. TTiis code is quite large and inefBdent 

The fimdamentM problems with the current method for doing serialization/deserializ^on i^^^^ 

40 spee4 and object traversal model. Code outside the JVM does not know the structure or graph of a Java object and 
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thus must traverse the object graph, pulling it apart, and ultimately must call upon the JVM. Traditional 
serialization and reflection mechanisms for storing and movmg Java objects are just not practical for aU types of 
devices, especially thinner devices. Some of the difficulties with Java reflection and serialization are that an 
objecfs graph (an object's transitive closure) reflection is difficult to do outside the JVM. Serialization is too large, 
5 requiring a large amount of code. In addition, serialization is a Java specific object interchange fonnat and thus may 

not be used with non- Java devices. 

The Jini distributed computing model requires the movement of Java objecte 

the serialization mechanism itself is not platform independent since it may not be used by non-Java platforms to 

send and receive objects. Serialization is a homogenous object fonnat - it only works on Java platfoims. 
10 Serialization uses the reflection API and may be limited by secmity concerns, which often must be addressed using 

native JVM dependent methods. TTie reflection API may provide a graph of objects, but is inefiBcient due to the; 

number of calls between the JVM and fte code calling the reflection methods. 

The use of Java reflection to serialize an object requires an appUcation to ping pong in and out of the JVM 

to pick apart an object one field at a time as the transitive closure of the object is dynamicaUy anafyzed. 
15 Deserializing an object using Java deserialization requires the application to work closely with the JVM to 

reconstimte the object one field at a time as the transitive closure of the object is dynamically analyzed. Thus, Java 

serialization/deserialization is slow and cumbersome while also requiring large amomits of application and JVM 

code as well as persistent storage space. 

Even for thin clients that do support Java, the Jini imi may not be practical for thin cUents with minhnal 

20 memory footprints and minimal bandwidth. Hie serialization associated wifli the JiniRMI is slow, big, requires Ihe 
JVM reflection API, and is a Java specific object representation. Java deserialization is also slow, big and requires 
a serialized-object parser. Even Java based thin cUents may not be able to accept huge Java objects (along with 
needed classes) being remmed (necessarily) across the network to the cUent as required in Jmi. A more scalable 
distributed computing mechanism is needed. It may be desirable for a more scalable distributed computing 
25 mechanism to address security concerns and be expandable to aUow for the passmg of objects, such as Java objects, 
and even to allow for process migration firom one netwoik mode to mother. 

Object based distributed computing systems need persistent storage. However, as discussed above, 
attempts at object storage are often language and operating system specific. In addition, these object storage 
systems are too complicated to be used with many small, embedded systems. For example, the Jmi technology 

30 JavaSpaces as pereistent object containers. However, a JavaSpace can only store Java objects and camiot be 
implemented m small devices. Each object in a JavaSpace is serialized and pays the above-described penalties 
associated with Java serialization. It may be desirable to have a heterogeneous object repositoiy for distributed 
computing tot may scale from small to large devices. 

JavaSpaces from Sun Microsystems, Inc.. draws from the parallel processing woik of David Gelemter. a 

35 computer science professor at Yale University. Gelemter's set of fimctions named "Linda" create a shared memmy 
space called a TupleSpace, in which results of a computer's processes or the processes themselves may be stored for 
access by multiple CPUs. Linda therefore provides a global shared memory fOT multiple processors. 

Another technology which extends Linda is TSpaces from IBM Corporation. TSpaces extends the basic 
Linda TnpleSpace framework wifli real data management and the ability to download new data types and new 
40 semantic fimctionality. TSpaces provides a set of network communication buffers and a set of APIs for accessing 
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those buffers. Like many of the solutions discussed above, TSpaces therefore uses a code-centric programming 
model and shares the drawbacks of such a modeL Additionally, TSpaces is implemented in the Java programming 
language and therefore requhes a Java Virtual Machme or other means of executing Java bytecode, such as a Java- 
capable microprocessor. Therefore, TSpaces may be mappropriate for smaU-footprint devices which cannot devote 
5 sufficient resources for executing Java bytecode. 

It is desirable in object oriented distributed systems to be able to locate object repositories and find 
particular objects within those repositories. As mentioned above, the Jini look-up server may not be practical for 
small devices with small memory footprints. A more efBcient mechanism for locating object stores may be 
desirable. 

10 It may be desirable in a distributed network computmg model for cHents to have the ability to locate 

services. Current network protocols either provide only a smgle standard service access interface that provides no 
security when accessing a network service or provides "all or nothing" access to the full range of the service's 
capabilities, which may include administrator or privileged fiinctlons. Also, current network protocols to locate 
services do not provide a flexible mechanism for finding services. Cunent protocols either do not provide any 

15 selective search capability at all (e.g. UPnP) or only provide a primitive keyword and attribute grammar mechanism 
(e.g. SLP). thus, current service discovery mechanism may be too inflexible in their security and search criteria 
mechanisms. 

Also, current service discovery models have a symmetric model for service location. However, it may be a 
waste of resources for certain service devices, such as devices whose fonctionality is available on a proximity basis, 
20 to support the discovery model. This is because such devices are already located by proximity (e.g. one device 
physically pointing to another one). Thus, an altemate light-weight discovery mechanism may also be desirable for 
such devices. 

Distributed object access also desh-es a fair and efficient sharing mechanism. As described above Jini 
cturrently uses a leasing mechanism to share objects. However, Jmi leases are time based which may result in a 
25 nmnber of problems. For exanQ)le, the cmxent object holder might have no idea how long to lease an object and 
may hold it too long. In addition, the use of time^based leases may reqmre that time be synchronized between 
multiple machmes. Moreover time based leasmg may require operating system support In addition, Jmi leases are 
established and released via RMI. Thus, the Jini leasing mechanism suffers from the above-noted problems with 
using RMI. In addition, the Jini leasing mechanism does not provide a security mechanism for establishing, 
30 renewing and canceling of leases. Other leasmg mechanisms may be desuable, 

GeneraUy speaking, it is desirable for small memory foot print mobile cHent devices to be able to run a 
variety of services, both legaQr and new, in a distrft>uted envhonmcnt The types of small cUents may incbde cell 
phones and PDA's with a variety of different netwoiidng interfaces, typically low bandwidth. Often these devices 
have very small displays with limited graphics, but they could mclude laptops and notebook computers, which may 
35 have a larger display and more sophisticated grapMcscapahiUties. The services may be a 

as well as control programs for devices such as printers. It is desirable for a mobUe cUent to be able to use these 

services vdierever tiiey may be. 

A mobile cHent will often be at a temporary dynamic network address, so networking messages it sends 
cannot be routed beyond that networidng mterface (otherwise there may be collisions when two different clients on 
40 diffei^nt networks have the same dynamic address). Mobile cHents often do not have the capabiUty for a fuU- 
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junction Wscr or other so^sticated softw^e. I.e displays .ay li.it fl.e tlient fro. ru^g ce^ 
applicadons. «naUpplication.odelsa.b.^^ 

changetotheapplicationrequiresrecompaationofthe application. ^ . 

It .ay be desirable for such « to have a .ecbaBism fo. finding and m^^^^ 
5 or services ll,e client may need to run even large legacy applications .Hch could not poss.^ly fit in the client'^ 

^.emory footprint AS discussed alx>ve. cunent technology, such as lini, 

devices Tl.epervasivenessofmobilethineUentsn.yalsorai.additionalneeds.Forexa.ple,it.^ 
tolocateservicesbasedo„thephysicallocationoftheuserandMs„K>bUeclient For example, infonnation about 
Ihe services in a local vicinity .ay be very help&l. such as local restaurants, weather, traffic n^s and .ov.e 
10 i„fonnation.Sinnlarly. infonnation about co.p«tingre.ut^, such. 

helpfid. current technologies do not provide an automatic .echanis. for locating sendees based on physical 
location of the cUent Another need rai^ by thir. .obile clients is that of addr^^^^ 
n^obUecUentstypicaUy do not contain ergonomic keyboards and .onitors. TT.e provision of such human fector 
servicesand/ortheabiUtytolocatesuchservicesinadistributedco.puttogenvirom^^^ 
15 Adis.ributedco.puting.odelshouldpn,videclien.swithawytofindtr.nsientdoc^^^^ 

It be desirable to have a .echanism for finding general^urpose documents (including services and/or service 
advertisements), .her. tl.e documer^ts are cKprcssed in a platform-independent ar.d language-independent typ.g 
suchasthatprovidedbyeXter.ibleMarlaxpLanguage(XML).Currentapproaches.incl^^ 
for ru4 Univer^al Plug and Play (UPnP). and the service location ft^^^^ 
20 purpose document lookup mechanism. For example, tire Jini lookup mechanism is linuted to Java Lavage typmg 
^ Jisther^forenotlanguage-independent tS>nP and SLP support a discovery protocol only fbr services, not f6r 

general-purpose documents. 

SUMMARY 

h. a distributed computing environment, a service discovery protocol may allow cUents to search for 
25 servicesCbothspaceservicesandspecificservicesortypesofse^ces). Service providers (or a listener agent) =>ay 
re^ondrse^ch requests by publishing or providh^ corresponding advertisements or mis to correspondnrg 
advertisements, men a service provider responds to a discovery search re.ue. (either dir^ 
ag.nO. the provider may choose to pubUsh a protected or ^ un-protected (complete) adverttsement A prelected 
iLment may include the set of information necess^ to obtain a complete ad^^ Pubbs^ga 
30 protected advertisement, forces the ch«.t to the obtain a valid o^en^ 

Living the complete un-protected advenisemerrt *om the service provider. A complete un-p.^ 
advertisement is needed to create a gate, »d therefore to use the ser^^^^ 
beforereceivinganadvertisementm^provide^addidonallevelofse^ 

credential ftat must be obtained to receive the complete advertisement may be the same secunty that . 

35 used to construct a gate to cormnunicate ^th the service .h«. the gate embeds the security credentral .each 

messaee to the sendee. vm*^ 
To obtain a complete advertisement, given a protected advertisement, a client obtains a c^^abdity 
credentialffomtl^especifiedauthenticationservicebysendingacredendalrequ^ credential request 

messagemaybesenttoanauthenticatedsendccURIspecifiedintheadver^^^^^ 
40 .oaccess Lntheclient'srequestisreceived.acapabiUtycreddrdalisgenerated.The^^^ 
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be ger^erated according to capabiUties requested by the client and/or fte client's level of authorization. Ti.. cUent 
then receives d.e capability credential in response to its request Tlie response may conte^ 
generate the complete advertisement Hus credential may be the same credential that the client's gate includes m 
each message sent to the service. If the advertisement was a protected advertisement, the client then may send an 
advertisement request message contaming the capability c^dential and an identification (e.^ IMD) of the servtce 
tothesecondURIspecifiedintheprotectedadvertisement The cUent then receives a complete advertisement lUe 
responsetothissecondmessageisthecompleteadvertisementoflhespecifiedservice. The complete advertisement 
andthecapabilitycredentialmaythenbeusedtocreateag.teusedtocommunicatewiththeserv.ce. 

to one embodiment, a method for accessing a service in a disml.uted computing enviromnent may mcta^^ 
cUentlocatingafi^tservicewithinthedistributedcomputrngeaviromnent To locate services, the client may send 
a search message in a data representational language. The search message may include search critena. such as 
service name and service type criteria. Services or a Hstener agent receiving the search mes^e may compare the 
search criteria to service advertisements to find advertisements that match the search criteria. Service 
advertisements may be data representational language documents that provide acce«. infonnation for conespondmg 
services. The cUent may then receive search response messages which indicate advertisements that matched the 

search criteria- ,.,..^-14. 

The client may then select a service that is desired to be accessed and request a capabihty credential to 
allow the client to access some or aU of that services capabilities. TTie cUent may send a capability credential 
request message to a UM specified m the sdect«i servipe advertisement This URI may be for an authentication 
service If the advertisemem was a complete advertisement mcluding schema mfonnation for messages to a 

service then the client may receive a capabihty credential for accessing the services complete capabihties. If the 
^advertiLmentwasaprotected advertisement which does not include access schema information,^ft^^ 

hich.de withm its capability credential request message an mdication of a set of desired capabilities for which it 
desires permission to access from the service. 

A client then receives the capability credential which indicates that the client is allowed to access at least a 
portion of the services capabilities. The capabilities for which the cUent is allowed access m,^ be the lesser of the 
set of capabilities which the client requested in its capabiUty credenti^ request message and the set of capabilrUes 
for which the chent is authorized. If die original advertisement mdicated m the response to the cUents search 
message was not a complete advertisement, the client then uses the capabUity credential to request a complete 
advertisement for its granted capabihties. The cUent may seud a advertisement request message to a URI specified 
the protected advertisement A service provider receivmg the advertisement request message may generate a 
custom complete advertisement for the capabilities mdicated by the cUents capability credential and return tins 
complete advertisement to the chent The chent may thea construct a message gate based on the complete 
advertisement for sending messages according to the schema in the complete advertisement to access the services 
35 capabilities. THe gate may include tiie capabUity a^lential m each message so that its messages may be 
authenticated by the service. 

Figure 1 is an iUustration of a conventional distributed computing 
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Figure 2 is an iUustration of a distributed computing environment prograimning model according to one 
embodiment; 

Figure 3 is an iUustration of messaging and networking layers for a distributed computing environment 
according to one embodiment; 

5 Figure 4 is an illustration of a discovery service for finding spaces advertising objects or services in a 

distributed computing environment according to one embodiment; 

Figure 5 illustrates client profiles supporting static and formatted messages for a distributed computing 
environment according to one embodiment; 

Figure 6 is an illustration of a distributed computing model employing XML messaging according to one 

10 embodiment; 

Figure 7 iUustrates a platform independent distributing computing environment according to one 
embodiment; 

Figure S is an illustration of a distributed computing model in v/Mch services are advertised in spaces 
according to one embodiment; 

15 Figure 9 is an illustration of a distributed computing model in which results are stored in spaces according 

to one embodiment; 

Figure 10 is an iUustration of cUent and service gates as messaging endpoints in a distributed computing 

model according to one embodiment; 

Figure 10b is an illustration a message endpomt generation according to a schema for accessing a service 

20 according to one embodiment 

Figure 11a iUustrates gate creation in a distributed computing environment according to one embodiment; 
Figure lib iUustrates gate creation and gate pairs in a distributed computing environment according to one 

embodiment; 

Figure 12 is an iUustration of possible gate components in a distributed computing environment accordmg 
25 to one embodiment; 

Figure 13 is an illustration of proxy client for a conventional browser to participate in the distributed 
computing environment according to one embodiment; 

Figure 14 illustrates the use of a method gate to provide a remote me^od invocation interface to a service 
in a distributed computing environment according to one embodiment; 
30 Figure 15 is an iUustration of the use of a space in a distributed computing environment according to one 

embodiment; 

Figure 16 illustrates advertisement structure according to one embodiment; 

Figure 17 iUustrates one example of advertisement state transitions that an advertisement may undergo 
during its Hfetime according to one embodiment; 
35 Figure 18 is an iUustration various space location mechanisms in a distributed computing envkonment 

according to one embodiment; 

Figure 19 is an iUustration of space federations in a distributed computing environment according to one 

embodiment; 

* Figure 20 is a flow diagram iUu?trating client formation of a session with a space service in a distributed 
40 computing environment accordmg to one embodhnent; 
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Figure 21 is an illustration of a space eventtype hierarchy for one embodiment; 

Figure 22 is a flow diagram illustrating service instantiation in a distributed computing environment 

accordiiig to one embodiment; 

Figure 23 is an illustration of a default space in a distributed computing environment according to one 

embodiment; 

Figure 24 illustrates an example of a device bridging proximity-based devices onto another transport 
mechanism to allow the services pn>vided by the proximity-based devices to be accessed by devices outside the 
proximity range of the devices, according to one embodiment; 

Figure 25 is an illustration of the use of lease renewal messages in a distn^uted confuting 

according to one embodiment; 

Figure 26a is a flow diagram iUustrating an authentication servi<* providing an authenti^^^^ 

a client according to one embodiment; 

Figure 26b is a flow diagram expanding on step 1002 of Figure 26a and illustrating an authenticatton 
service generating an authentication credential according to one embodiment; 

Figure 27 illustrates one embodiment of a bridging mechanism; 

Figure 28 illustrates an example of a space discovery protocol mapped to an external discovery service 

according to one embodimeni; 

Figure 29 illustrates bridging a client external to the distributed computing environment to a space in the 
distributed computing environment according to one ranbodiment; 

Figure 30 is an illustration of a proxy mechanism according to one embodiment; 

. Figure 31 illustrates one embodiment of a client with an associated display and display service accordmgto 

one embodiment; 

Figures 32A and 32B Ulustrate examples of using schemas of dynamic display objects according to one 
embodiment; 

Figure 33 A illustrates a typical string representation in the C programming language; 
Figure 33B illustrates an example of a conventional string fimction; 

Figure 33C illustrates an efficient method for representing and managmg strings in general, and in small 
footprint systems such as embedded systems in particular according to one embodiment; 

: Figure 34 iflustral^ a process of moving objects between a cUent and a service accordmg to one 

embodiment; , . / xini4> 

Figures 35a and 35b are data flow diagrans illustrating embodiments where a virtual machme (e.g. JVM) 

includes extensions for compiling objects (e.g. Java Objects) into XML representations of the objects, and for 
decompiling XML representations of (Java) objects into (Java) objects; 

Figure 36 illustrates a cUent and a service accessing store mechanisms ia the distributed computmg 
environment, accordmgto one onbodiment; 

Figure 37 iUustrates process migration using an XML representation of the state of aprocess, accordmgto 

one embodiment; 

Figure 38 illustrates a mobile cUent device accessing spaces in a local distributed computing network. 

accordingto one embodiment; • 
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Figure 39a illustrates a user of a mobfle device discovering the location of docking stations, according to 
one embodiment; 

Figure 39b iUustrates a mobile cUent device connecting to a docking station/according to one embodiment 
Figure 40a illustrates an embodiment of embedded devices controlled by a control system and accessible 
5 within the distributed computing environment, according to one embodiment; 

Figure 40b iUustrates a device control system connected via a network (e.g. the Internet) to embedded 
devices accessible within the distriTjuted computing environment, according to one embodiment; 
Figure 41 is a flow chart illustrating service discovery according to one embodiment; 
Figure 42 is a flow chart illustrating an example of locating service advertisements according to one 
10 embodiment; 

Figure 43 is an illustration compares the difference in the discover process when the published 
advertisement is a complete advertisement versus a protected advertisement, according to one embodiment; 

Figure 44 is a block diagram of an example of a system in which a cUent device directly discovers a service 
on a service device over a proximity link, according to one embodiment; and 
15 Figure 45 is a basic flow diagram illustiatiDg cUent discovery of a proximity service, according to one 

embodiment 

While the invention is susceptible to various modifications and altem^ve forms, specific embodiments 
thereof are shown by way of example in the drawings and will herein be described m detaiL It should be 
understood, however, that the drawings and detailed description thereto are not intended to limH the invention to the 
20 particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives 
felling withm flie spirit and scope of the present invention. 

DETAILEP DESCRIPTION QV EMBODIMEN TS OF THE INVENTION 

25 Overview of Embodiments for Distrib uted Computme 

Turning now to Figure 2, a distributed computing environment programming model is iUustrated. The 
model includes API layer 102 for faciUtating distributed computing. The API layer 102 provides an interface that 
facilitates clients comiectmg to services. The API layer 102 is concerned with the discovery of and the comiecting 
of cUents and services. The API layer 102 provides send message and receive message capabilities, ini^ 
30 API may provide an interfece for simple messages in a representation data or meta-data format, such as in the 
extensible Mark-up Language (XML). Note that while embodiments are described herein employing XML. other 
metaKlata type languages or fonnats may be used in ahemate embodiments. In some embodiments, the API layer 
may also provide an interface for messages to commmiicatB between objects or pass objects, such as Java objects. 
API's may be provided to discover an object repository or '^pace", find a particular object, claim and release an 
35 object, and write or take an object to or from the object repository. Objects accessible through API layer 102 may 
be represented by a representation data fonnat, such as XML. Thus, an XML representation of an object may be 
manipulated, as opposed to flie object itself. 

API layer 102 sits on top of a messaging layer 104. The messaging layer 104 is based on a representation 
■ data format, such as XML. In one embodiment, XML messages are generated by messaging layer 104 according to 
40 calk to the API layer 102. The messaging layer 104 may provide defined static messages that may be sent between 
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clients and services. Messaging layer 104, may also provide for dynamicaUy generated messages. In one 
embodiment, an object, such as a Java object, may be dynamically converted into an XML representation. The 
messaging layer 104 may then send the XML object representation as a message. Conversely, the messaging layer 
104 may receive an XML representation of an object The object may then be reconstituted from that message. 
5 In one embodiment, messages sent by messaging layer 104 may include several basic elements, such as an 

address, authentication credentials, security tokens, and a message body. The message system transmission and 
receive mechanisms may be completely stateless. Any notion of state may be embedded in the message stream 
between sender and receiver. Thus, message transmission may be done asynchronously, hi a jprefeixed 
embodiment, no connection model is imposed. Thus, transports such as TCP are not requu-ed. Also, error 
10 conditions may be limited to non-delivery or security exceptions. 

Messaging layer 104 sits on top of a message capable networking layer 106. In a preferred embodiment, 
messagmg layer 104 does not require that a particular networking protocol be used. TCP/IP and UDP/IP are 
examples of message capable protocob that may be used for message capable networking layer 106. However, 
other more specialized protocols such as the Wireless AppHcation Protocol (WAP) may also be used. Other 
15 possible message protocols are frDA and Bluetooth network drivers beneath tiiie transport layer. Networidng layer 
106 is not limited to a single reliable connection protocol, such as TCP/IP. Therefore, connection to a larger variety 
of devices is possible. 

In one embodunent, message capable network layer 106 may be implemented from the networkmg classes 
provided by the Java2 Micro Edition (J2ME) platform. Hie Java2 Micro Edition platform may be suitable for 
20 smaller footprint devices that do not have the resources for a fiiU Java platform or in which it would not be efficient 
to run a fiiU Java platform. Since J2ME aheady provides a message capable femily of networking protocols (to 
support sockets), it foUows that for the small footprint cost of addmg messagmg layer 104, distributing computing 
fecilities may be provided for small devices that aheady include J2ME. 

Message capable networidng layer 106 may also be provided by the Java Development Kit's (JDK) 
25 java,net networidng classes. Alternatively, any message capable networkmg facilities may be used for message 
capable networidng layer 106. hi a preferred embodiment, a reliable transport is not required, thus embedded 
devices supporting an unreUable data gram transport such as UDP/IP may still support the messaging layer. 

Thus, thin clients may participate in a distributed computing environment by simply addmg a tiim 
messaging layer 104 above a basic networking protocol stack. As shown in Figure 3, a basic system includes 
30 messaging layer 104 on top of a networidng layer 106. The networkmg layer may provide for reliable messages, 
e.g. TCP, or unreliable messages, e.g. UDP. The Internet Protocol (IP) is shown in Figure 3 as ^ example of 
protocol tiiat may be used in networking layer 106. However, the distributed computing environment does not 
require IP. Other protocols my be used in the distributed computing environment besides IP. A network driver 
such as for Ethernet, Token Rmg, Bluetoodi, etc. may also be part of the networking layer. Many small clients 
35 ah^ady provide a networic driver and transport protocol such as UDP/IP. Thus, with the addMon of the thin XML 
based messaging layer, the device may participate in the distributed computing environment. 

Thus, tiie foundation for the distributed computing environment is a simple message passmg layer 
implemented on top of rehable connection and/or unreKable data g^ams. The messaging technology is very different 
from communications technologies employed in other distribution computing systems, such as Jini which employs 
40 the Java remote method invocation (RMI). The message passing layer 104 supports an asynchronous, stateless style 
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of distributed programming, instead of the ^chronous, state-full style predicated by RM. Moreover, message 
passing layer 104 is based on a data representation language such as XML and thus copies data, but not code, from 
source to destination, unlike RML By using a representation data language, such as XML, messaging layer 104 may 
interoperate with non-Java and non-Jini platforms in a seamless fashion because Java code is not assumed on the 
5 sending or receiving end of a message. Moreover, unlike EMI, messagmg layer 104 does not require a rehable 
transport mechanism such as TCP/IP. 

The message passing layer may provide simple sendQ and receiveQ methods to send a message specified as 
an array or string of bytes, for example. The sendQ method may retum immediately, performing the data transfer 
asynchronously. Por flow contix)! purposes a callback method may be supplied which is invoked in the event that 
10 the sendO method throws an exception indicating it cannot handle the sendQrequ 
synchronous and may return the next available message. 

The message passmg layer may also provide methods for storing XML representations of objects, services 
and content m "spaces". A space is named and accessed on the network using an URI (Uniform Resource 
Identifier). The URI may be a UKL (Uniform Resource Locator) or a simpler version of a URL. In some 
15 embodunents, the URL class may be too large. For such embodiments a simpler resource locator may be used that 
specifies the protocol for moving the messages between client and server, protocol dependent host ID, protocol 
dependent port ID, and a space name. 

An XML representation of an object may be added to a space using a writeQ method provided by the 
messaging layer. In one embodhnent, the object and the cUent-specified name may be suppHed as parameters. Li 
20 one embodiment, the write method may translate the object mto its XML representation. A takeQ method may be 
provided to retum the object and remove it from the space. A ^dQ method may be provided to return a specified 
object from its XML representation m a space. The findQ method may also be used to return an array of matching 
objects m a space given a class. Each of these space methods is implemented usmg the message-passmg layer. A 
lease mechanism may also be provided, as described in more detail below. 
25 A discovery service may be provided for clients as a general search fecility that may be used by a client to 

locate a particular space. Rather than attenq)t to define a complicated search prot;ocol which may not be feasible for 
a thin cUent to implement, the discovery service may offload the actual search to XML-b^ed search facilities, 
leavmg the discovery service sunply to provide interfece fimctionaHty to the client ITie approach is illustrated in 
Figure 4. In one embodhnent, the discovery service receives a string specifymg something to locate, and it sends an 
30 XML message to a known discovery front-end (perhq)S found in a default space), which then parses the string and 
makes a correspondmg XML query to a search facility (which may be an mtemet search fecility). Hie discovoy 
front-end may parse what it obtains firom die search fecility and repackage it as an array of strmgs (each string may 
be a URI for each found space) which it may send m an XML message to the client It should be noted tiiat the 
discovery service does not requke that the messagmg be atop a connection-oriented transport Thus, even very thm 
35 clients that do not have TCP could use such a discovery service. The discovery front-end makes it possible for the 
cHent to discover spaces without a browser or search feciUty on the cUent The cHent only needs a shiq>le feciUty 
that sends a string that specifies keywords to the front-end, which interfaces with a search facility. 

A client may be any platform that can send a message using at least a subset of the API and messa^g 
layers. In one embodiment the API layer may provide for both static (or raw) and foniiatted (or cooked) messages. 
40 A server may be any platform capable of receiving and fiilfilling message requests. An e:q)Ucit raw message send 
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may be provided that moves a series of bytes from a client to a server or to another client The message type may be 
specified as reliable (e.g. TCP) or unreliable (e,g, XJDP). The smallest of devices may use raw unreliable message 
passing as their sole means of participation in the distributed computing environment The device may use these 
messages to announce its presence and its status. Such smaU devices may aliso receive raw messages to implement 
5 certain functions, such as turning a feature on or off. 

Message-based services such as spaces may send and receive reliable formatted messages. A space 
message may be formatted with a well-defined header and with XML. In one embodiment, a foimatted message 
send may occur when a client uses a space method to claim, write, or take objects from a space. The message 
contents maybe dynamically formatted in XML and contain well-defined headers. Figure 5 illustrates client profiles 
10 supporting formatted and static messages. By using static naessages, small devices may use a smaller profile of code 
to participate in the distributed computing environment For example, a small device could just send basic 
pre-defined messages. Depending on the client, the static pre-defined messages may consume a small amount of 
memory (e.g. <200 bytes). Static messages may also be an option even for larger devices. On the other band, the 
dynamic XML messages may be useful when object values are not known at compile time. 
15 Turning now to Figure 6, a distributed computing model is illustrated that combines a messagmg system 

with XML messages and XML object representation. The platform independence of XML may be leveraged so that 
the system may provide for a heterogeneous distributed computing environment Thus, cHent 110 may be 
implemented on almost any platform instead of a particular platform like Java, The messagmg system may be 
implemented on any netwoik capable messaging layer, such as Intemet protocols (e.g. TCP/IP or UDPAP). Thus, 
20 the conqjuting environment may be distributed over the Intemet In one embodiment, the messaging system may 
also use shared memory as a quick interprocess message passing mechanism when the client and/or space server 
and/or service are on the same computer system. The distributed computing model of Figure 6 may also be very 
scalable because almost any size client can be configured to send and/or receive XML messages. 

As shovm in Figure 6, two kinds of software programs may nm in tiie distributed computing model: 
25 services 1 12 and clients 110. Services 1 12 may advertise their capabilities to cfients wishing to use the service. The 
services 112 may advertise thek capabilities in spaces 1 14. As illustrated in Figure 7, clients 110 and services 1 12 
may or may not reside within the same netwoik device. For example, devices 120 and 124 each support one chent, 
whereas service 1 12a and client 1 10b are implemented in the same device 122. Also, as illustrated in Figure 7, no 
particular platform is required for the devices to support the cHents and services. For example, device 120 is Java 
30 based, whereas device 124 provides a native code runtime environment 

A device may be a networking transport addressable imit Example devices include, but by no means are 
limited to: PDAs, cellular/mobile phones, notebook compirters, laptops, desktop computers, more powerful 
computer systems, even siq)ercomputers. Both clients and services may be URI-addressable instances of software 
(or firmware) that run on devices. Usmg the distributed computing environment architecture, a client may run a 
35 service. A space is a service that manages a repository of XML documents. Even though it is redundant, the term, 
^ace service, may be used herein for readabili^. A software component may be both a chent and service at 
different times. For example, when a service uses a space (e.g. to advertise itself), that service is a client of the 

space. . 

. Figure 8 illustrates the basic model of the distributed computing environment- in one embodiment The 
40 distributed computing environment may connect clients 110 to services 112 throughout a network. The network 
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may be a wide area network such as the Internet The network may also be a combination of networks such as a 
local area network (LAN) connected to a wireless network over the Internet As shown in Figure 8, a service 112 
publishes an advertisement 132 for itself(represented in XML) in a space 114. The advertisement 132 specifies the 
servicers XML schema and URI address. Then, a client 110 may look up the advertisement 132. The client 110 
5 may use the advertisement 132 to mstantiate a gate 130. The gate 130 allows the client 110 to run the service 1 12, 
by sending (and receiving) XML messages to (and from) the service 112. 

Some results of running a service may be returned to the client in an XML message. However, since other 
results may be too large for a small cHent to receive and consume at once, a service 1 12 may put those results or an 
XML representation of the results 134 in a space 114, as shown in Figure 9, and return them by reference (m an 
10 XML message) to the client 110, rather than by value. Examples of methods of returning a reference to results 
include, but are not limited to: returning in the message a URI referencing flie results in a space, and: returning in the 
message an XML document including the URI of the results. Later, the client 1 10 may access the results, or pass 
them by reference to ano&er service. The space in which results may be stored may be different from the space in 
which the service is advertised. 
15 In one embodiment, the distributed computing environment uses XML for content definition, advertisement 

and description. New content for the distributed computmg environment (messages and advertisements for 
example) are defined in XML. Existmg content types (e.g. developed for other environments) may also be 
described using XML as a level of indirection (meta-data). XML provides a powerM means of representmg data 
throughout a distributed system because, similar to the way that Java provides universal code, XML provides 
20 universal data. XML is language agnostic and is self-describing. The XML content may be strongly typed and 
vaUdated using schemas. Using a provided XML schema, the system may ensure that only valid XML content is 
passed in a messagis. XML content may also be translated, mto other content types such as HTML and WML, 
Thus, cUents that do not understand XML may still use the distributed computing environment services. 

In one embodiment, the distributed computing environment messages may define the protocol used to 
25 connect clients with services, and to address content in spaces and stores. The use of messages to define a protocol 
allowsmany different kmds of devices to participate in the protocol. Each device may be free to implement the 
protocol m a manner best suited to its abilities and role. For example, not all devices are capable of supporting a 
Java runtime environment The distributed computing environment protocol definition does not require nor imply 
the use of Java on a device. Nor does it preclude it 
30 A service's capabilities may be expressed in temis of die messages the service accepts. A service's message 

set may be defined using an XML schema. An XML message schema defines each message format using XML 
typed tags. The tag usage rules may also be defined in the schema. The message schema may be a component of an 
XML advertisement along with the servicers message endpoint used to receive messages. The distributed computing 
environment may allow cfients to use aU or some subset of a service's capabilities. Security policies may be 
35 ' employed to enforce the set of capabilities given to a client For example, once a set of capabilities has been given 
to a cUent, the client may not change that set without proper autiiorization. This model of capability definition 
allows for services levels that range from a base set of capabiUties to an extended set Extensions may be added to 
services by addmg to the nmnber of recognized messages. 

In one embodiment, all operations in the distributed computing envkonment are embodied as XML 
40 messages sent between clients and services. Storage (both transient and persistent) providers are examples of 
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services that enable clients and services to store, advertise, and address content Clients and services may find each 
other and broker content using a transient storage space. Services may place a content or service advertisement in a . 
space. The advertisement may describe the content type or the capabilities of the service. Clients may subsequently 
browse spaces looking for advertisements that match a desired set of capabilities. When a client finds a matching 
5 advertisement, a communication channel may be established which may enable bi-directional message passing to the 
service backing the advertisement, hi one embodiment, the communication channel is authenticated Resulte (which 
are just another content type) from service operations may be returned directly to tiie client m a response message, 
advertised and stored in a space, or advertised in a space, but stored persistently. Stored results may be addressed 
using a URI (e.g. returned in the response message) and may have an associated authentication credential. 

10 

Message Gates 

As discussed above, the distributed computmg environment leverages off the use of a data description . 
language, such as XML. XML may be used to describe a target entity (e.g. document, service, or client) to an extent 
such tiiat code may be generated to access that entity. The generated code for accessing the target entity may be 
15 referred to as a message gate. Thus, in one embodiment, the distributed computing envkonment differs from other 
distributed computing environments in that instead of passmg the necessary code between objects necessary to 
access the other object, the environment provides access to XML descriptions of an object or target so that code 
may be generated based on the XML description to access the target The distributed computing environment may 
use an XML schema to ensure type safety as well as a programming model (e.g. supported messages) without having 
20 to agree upon language specific APIs, just XML scheraas. 

Code generated from an XML schema may also incorporate the language, security, type safety, and 
execution environment characteristics of the local platform. The local platform may thus have control over the 
generated code to ensure that it is bug-free and produces only vahd data according to the schema. The generated 
code may conform to the client's code execution environment (e.g. Java, C++, Smalltalk), as well as its management 
25 and security framework (Web-server and/or operatujg system). 

Note that the distributed computing environment does not require that code generated from an XML 
schema be generated **on the fly" at nmtime. Instead, some or all of the code may be pre-generated for categories 
(or classes) of services, and then linked-in during tiie platform build process. Pre-generation of code may be useM 
for some clients, such as embedded devices, where certain XML schemas are aheady known. In one embodiment, 
30 some or all of the code doesn*t actually have to be generated at all A private code-loading scheme (within the 
client) might be used in one embodiment to augment the generation process, hi addition, the distributed computing 
environment may specify, in some embodiments, an mterfece to download code for additional features m accessmg 
a service (see, e.g., message conductors described below). Typically- such downloaded code may be small and the 
client may have the option to download the code or not 
35 The phrase "generated code^* may refer to code that origmates within the client under tiie control of the 

chent code execution envfronment, or to code that is generated elsewhere (such as on the service system or on a 
space service system) and that may be downloaded to the cfient system after generation. Bindmg time, however, 
may be at runtime. At runtime, the generated code may be bound to a service address (URI), so that a message may 
be sent to that service mstance. 
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As discussed above, the interface to any service in the dstributed computing environment may be specified 
by an XML schema, defining the set of messages that a client may send (and receive from) that service. As 
illustrated in Figure 10, the client 110 and service 112 may each construct a message gate 130 for communicatmg 
accordmg to the specified XML schema. From the XML schema advertised for the service 1 12 (and possibly other 
information in the service advertisement), a message gate 130a or 130b may be constructed by the client 110a or 
1 10b respectively. A corresponding message gate 130c generated from the same XML schema may also exist on the 
service 112a. A gate 130 is a message endpoint that may send and/or receive type-safe XML messages, and that 
m^ verify the type correctness of XML messages when sending and/or receiving the messages. The message gate 
may also provide for authentication and/or other security mechanisms to ensure that tbe message endpoint is secure. 
In one embodiment, message gates are always seciire. 

The distributed computing environment messaging lay^ described above may be coupled to or may be part 
of die gate. The messaging layer asynchronously delivers an ordered sequence of bytes, using a networking 
transport, fit>m the sender to the receiver, mamtairdng the notion on both the sender and receiver tbat this sequence 
of bytes is one atomic Unit, the message. The distributed computing environment does not assume that the 
networking transport is IP-based. Instead, the messaging layer may sit atop whatever networking transport layer is 
supported by the device. 

Message gates may provide a mechanism to send and receive XML messages between clients and services. 
The XML messages may be "typed". For example, the messages may include tags to indicate if a message data field 
is, e.g., integer, floating point, text data, etc. A message gate may be constructed to verify the type coirectness of 
messages sent or received. A message gate also may authenticate (e.g. securefy identify) the sender of a received 
message. An XML schema may be provided for a service that describes the set of messages accepted by the service 
and/or sent by the service, A message gate may verify the correctness of messages sent or received according to the 
XML schema for which the gate is constructed. 

A gate may be constructed as a single atomic unit of code and data that performs type verification and/or 
message correctness verification and/or sender identification for mess^es between a client and a service m the 
distributed computing envkonment In one embodiment, once the atomic unit of code and data for a message gate 
has been created, it cannot be altered as to its typing, messj^e descriptors, and sender identification. In another 
embodiment, the gate may be modified as to the contents of the message schema after the gate is created, mcluding 
deleting, adding, or modifying messages in the message schema. 

A message gate is the message endpouit for a client or service in the distributed computing environment A 
message gate may provide a secure message endpoint that sends and receives type-safe XML messages. Messages 
gates may allow cfients and services to exchange XML messages in a secure and reliable feshion over any suitable 
message transport (e.g. HTTP). For a client, a message gate may represent the authority to use some or all of a 
service's capabilities. Each capability may be expressed in teraos of a message that may be sent to a service. Each 
such message may be sent through a client message gate which may verify the correctness of tiie message. The 
message may be received by a service message gate which may autiienticate the message and verify its correctness. 

A message gate may provide a secure communication en^oint that type checks XML messages. As 
further discussed below, a message gate may also provide a mechanism to restrict the message flow between clients 
and services. In one embodiment when a client desires to access a service, a client and service message gate pair is 
created, if not akeady existing. In one embodiment, the service message gate may be created when the service 
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rcceives a first message from the client message gate. In one embodiment, one or more service message gates may 
be created when the service is initialized, and may be used to pair with client message gates when created. The 
creation of a message gate may involve an authentication service that may negotiate the desired level of security and 
the set of messages that may be passed between client and service. In one embodhnent, the authentication service 

5 may accept a client ID token (also referred to as a cUent token), a service ID token (also referred to as a service 
token), and a data representation language message schema that descrft)es the set of data representation language 
messages that may be sent to or received from the service. For example, messages may be described that may be 
sent from a client to a service to invoke the service or to invoke aspects of the service. Messages may also be 
described that are to be sent from the service, such as response messages and event notification messages. Refer to 

10 the Authentication and Security section below for a further discussion of how the authentication service may be used 

in the construction and use of message gates. 

A client message gate and a service message gate pair may allow messages to be sent between the client 

and the service. In one embodiment, message gates may be created that only send and/or receive a subset of the 
total set of messages as described in tiie message schema for a service. This limited access may be used whhin the 
15 distributed computing environment to unplement a policy of least privilege whereby clients are only given access to 
specific individual message types, based on a security policy. Refer to the Authentication and Security section 
below for a fiffther discussion of security checks for gate usage and gate creation. 

Client and service gates may perform tiie actual sendmg (and receiving) of the messages from the client to 
the service, using the protocol specified in the service advertisement (URI of service in the service advertisement). 
20 The client may run the service via this message passing. A message gate may provide a level of abstraction between 
a client and a service. A client may access a service object through a message gate mstead of accessing the service 
object directly. Since the gate abstracts the service from the cUent, the service's code may not need to be loaded, 
and then started, until the client first uses the service. 

The cHent gate may also perform verification of the message against the XML schema, or verification of 
25 the message against the XML schema may be perfonned by the service gate, e.g. if the cUent mdicates it has not yet 
been verified. In some embodiments, verification may not be practical for sunple clients and may thus not be 
requked at the client In some embodiments, verification may be perfonned by the service. The gates may also 
perform authentication enablement and/or security schemes. In one embodiment, if a client does not support the 
protocol specified in the service advertisement, then it may not be able to constnict the right To avoid this 

30 problem, service advertisements (used for gate construction) may include a Ust of possible URIs for a service, so a 
variety of clients may be supported. 

A basic message gate may implement an API to send and receive messages. The API moves data (e.g. 
XML messages) in and out of &e gate, validating messages before sending and/ or upon receiving. In one 
embodmient, message gates may support a fixed minimum API to send and receive messages. This API may be 

35 ejrtended to oflier features as discussed below. As iUustrated in Figure 10b, a gate 130 may be generated according 
to an XML schema 132. The generated gate code verifies messages based upon the XML schema. The gate may 
verify correct message types and/or content through the messa^^ As iUustrated in Figure 10b, through frie 
message API a verified message may be sent to a service. The message may be received by a corresponding gate at 
the service. In response to the message, the service may generate results 180. The service may retmn result data 

40 182 through its gate. The results data m^ be the results themselves or a reference to th^ 
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results stored in a space.. In various embodiments, the message API may support synchronous messages (request- 
response), asynchronous messages (response is disconnected from request), unicast messages (point to pomt). multi- 
cast messages (broadcast), and publish and subscribe (event messages), for example. Other type of messages may 
also be supported, such as remote method invocation messages. 

Each message sent by a gate may include an authentication credential so that the receiving gate may 
authenticate the message: Each message may also include a token which inchides information allowing the 
receiving gate to verify that the message has not been compromised or altered. For example, the sender may 
compute a hash or checksum of the message which may be verified by the receiver. Ihc sender may also encrypt 
this token and/or the entire message using the sender's private key and inay include in the encrypted message the 
corresponding public key so that the receiver may verify that the token was not changed. See the section below on 

Authentication and Securi^. 

A pair of message gates may provide a mechanism for communic^g requests from clients to services and 

response from services to cUents. Two associated message gate endpoints may be used to create a secure atomic bi- 
directional message channel for request-response message passing. TTius. the distributed computing environment 
5 may employ a message transport in which a message gate exists on both the client and the service sides. The two 
gates may work together to provide a secure and reliable message channel. 

Tuniing now to Figure 11a, an illustration is provided for one embodiment showing construction of a gate 
130a in a cUent 110 from a service advertisement or other service description 132. The client may have a gate 
fectory 140 that is trusted code on the client for generating gates based on XML service descriptions. The use of the 
20 gate factory 140 may ensure lhalthe gate it generates is also trusted code, andlhatthe code is correct with respect to 
Ihe service advertisement As shown in Figure 1 lb, a gate 130c may also be constructed at a service 112. Tbe cUent 
gate 130a and the service gate 130c provide message endpoints for communications between the cUent and service. 
In one embodiment, the pieces the gate fectory needs to construct a gate 130 are the XML schema of the service 
(from the service advertisement) and the URI of the service (from the service advertisement). In another 
25 embodiment, an authentication credential may also be obtained and used in gate construction by rmming an 
authentication service specified in the service advertisement 

A gate factory may provide a trusted mechanism to create message gates. In some embodhnents, in order 
to ensure that a message gate is a trusted message endpoint. the code used to create the gate must be trusted code. A 
gate factory 140 may be a trusted package of code that is used to create gates. In one embodiment, each cUent 

30 service device platform that desires to send and receive messages in Ibe distributed computing enviromnent may 
have a gate factory. In some embodiments, gates may be pie-cohstructed by a separate gate factory so that adevice 
with pre-constructed gates may not need a fiiU gate factory' or may include a partial gate fectory for binding a 
service URI and/or an authentication credential to the pre-constructed gate at nmtime (e.g. when messaging is 
desired). 

35 A gate fectory for a device may generate gate code that may incorporate the language, security, type safely, 

and/or execution enviromnent characteristics ofthe local device platform. By constructing gates itselt a device has 
the ability to ensure that Ihe generated gate code is bug-free, produces only valid data, and provides lype-safely. An 
advantage of a device generatmg its own gate code as opposed to downloading code for accessing a service is that 
the cUent code management environment has the control. The generated code may confonn to the client's code 

40 execution environment (e.g. Java, Smalltalk), as weU as its management and securify frameworic (Web-server 
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and/or operating system). Generated code is also trusted code, because the client's runtime environment was 
involved in its creation. Trusted security information therefore may also be added by the trusted generated code. 
Thns, a device may receive an XML message schema for a service and then construct a gate based on that schema to 
access the device. The XML schema may be viev^ed as definuig the contract with the service and the generated gate 
5 code as providing a secure way to execute the contract Note that open devices, m which un-trusted (e.g. 
downloaded) code may be mn, may be configured so that gates may be generated only by trusted code. Open 
devices may employ a process model in which gates are enclosed in a protected, isolated code container that is not 
accessible to tools, such as debuggers, capable of discovering the gate's implementation, especially the gates 
authentication credential. 

10 A gate factory 140 may negotiate on behalf of a client with a service to create a gate to send messages to 

the service. Similarly, a gate may be constructed at the service to receive messages from the client gate and send 
messages to Ihe client gate. Together, the client and service gates may form a secure bi-directional commmucation 
channel. 

A gate factory may provide a level of abstraction m gate creation. For example, \^en a client desires to 
15 use a service, mstead of the client direcOy creating a gate to access the service, tiie gate may be created by a gate 
factory as part of instantiating the service. 

The gate factory may create or may include its own trusted message gate that is used to communicate with 
an authentication service (e.g. specified by a service advertisement) to receive an authentication credential for the 
gate being constructed. For services that do not restrict access, a gate may be constructed without an authentication 
20 credential. The gates for such services may not need to send an authentication credential with each message suice 
die service does not restrict access. The authentication service is an example of a service that does not restrict 
access, in one embodiment. Thus, a gate factory may be configured to optimize gate construction by checkmg 
whether a service restricts access. If the service does not restrict access, then the gate factory may avoid ruiming an 
authentication service as part of gate construction and may avoid included provisions for an authentication 
25 credential as part of the constructed gate. The gate factory may also receive or download an XML message schema 
(e.g. specified by a service advertisement) to create a gate matching that schema. The gate factory may also 
receive or download a URI for the service and/or for a service message gate for use m creating the client message 
gate to communicate with the URI. 

In addition, another gate construction optimization may be employed for certain clients that do not deske to 
30 perfonn checking of messages agamst a service's XML schema. The client may be too thin to perform the checkmg 
or may rely on the service gate to perform the checkmg or may simply choose not to perform the checking (e.g. to 
reduce gate memory footprint). The gate fectory may be configured to receive an indication of whether or not a gate 
should be constructed to verify messages against the provided XML schema. In some embodiments, certain clients 
may have a gate fectory that does not provide for message verification against a schema for its constructed gates. In 
35 some embodiments, gates may be pre-constructed not to verify messages. In some embodnnents, a gate may be 
constructed to verify outgoing messages only, or verify received messages only. Thus, in some embodnnents, a 
chent may avoid or may chose to avoid building some or all of the gate code that checks the messages against the 

XML schema, * 

In some embodiments, devices may maintain a cache of gates to avoid constructmg tiiem each tune the 
40 same service is run. For example, when a new gate is constructed by a gate fectory, the gate may be mamtained in a 
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gate cache. When the gate is no longer being used, it is kept in the gate cache instead of being deleted. If the gate 
cache becomes full, one or more gates may be removed from the gate cache accordmg to a cache replacement 
algorithm, such as least recently used. When the gate factory is caUed to construct a gate, it first checks the gate 
cache to see if a matching gate already exists so that construction of a new gate may be avoided 
5 The building of a gate may be made lightweight by appropriate reuse of pieces used to construct other 

gates. Certain portions of each gate may be the same, and thus may be reused from gate to gate, such as parts of the 
message verification code. Also, for some devices, common gate code may be built mto the system software for the 
device and shared by all gates on that device. Thus, the gate factory may avoid rebuildmg this common code for 
each gate. Instead, the gate factory may simply bind the gate to this system software portion. For example, a system 
10 software portion may be provided to handle the message layer over whatever transports are provided on the device. 

Space services in particular may be good candidates for many of the gate construction optunizations 
described above smce a service gate constructed for a space service may perfonn many of flie same functions as 
other service gates for that space service. Refer to the Spaces section below for more information on space services. 
In some instances, a more efficient form of method invocation may exist For example, if the target service 
15 runs in tiie same Java Virtual Machine as the client application, a more efficient form of method invocation may be 
to create a Java dynamic proxy class for the service. In such a case, a java.lang jeflect JVIethod invocation m^ be 
faster than sending a message. A gate binding time procedure may check for such an optimization and use it instead 
of running the gate factory to create a gate or bind an existing gate. 

In one embodiment, such as for special-purpose clients or small embedded devices, the generation of gate 
20 code at runtime may not be desirable due to memory consumption and code generation time. Thus, uxstead of 
having a gate factory that generates gates at runtime, in some embodnnents gates may be pre-generated and built 
into the device. For example, message gates may be generated during; the build of embedded software as a means of 
including a built-in secure message endpomt that does not have to be constructed at runtime. Thus, a client with 
built-in gates may not need a full gate factory, or may require only a partial gate factory for perfomimg certain 
25 runtime bindmg to a built-in gate, such as for the XJia and/or authentication credentid^ 

A generation tool may be provided for the pre-construction of gates. The generation tool may include an 
XML parser, a code generator and a code compiler. In one embodiment, the code generator may be a Java source 
code generator and tiie code compEer may be a Java code compOer. During tiie bmld of the software for which 
built-in message gates is desired, the generation tool is run with mput from aU the relevant XML scliemas for which 
30 gates are desired 

As an exmnple, if it is desired for a device to have a built-in message gate that can send and receive 
messages from a digital camera, the build of the device software may include ninning the gate gen^ 
the camera's XML message schema as input The XML schema may be parsed by the XML parser that may convert 
die XML schema into an mtemal form suitable for quick access during a message verification process. The tool's 

35 code generator may provide source code for a gate corresponding to the camera's schema. In some embodiments, 
tiie generation tool may also compile the source code and tiie gate code may be linked into the software package^for 
the device. At runtime, tiie camera service may be discovered in the distributed computing environment The 
message URI for tiie camera service may be bound to the built-in gate for the camera within the device. The bindmg 
of the URI to the pre-constructed gate may be performed by a gate constructor witiiin the device. This gate 

40 constmctor may be a much smdler, simpler gate factory, men the cam^serv^^^ 
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camera service is passed to the gate constructor as an XML message. The gate constructormay then bind the URI to 
the pre-constmcted gate. 

•n»us, a gate may be partiaUy or foUy generated at runtime, or a gate may be pre-generated before runtime 
Willi a binding process (e.g. for aURI or credential) perfpnned at runtime. In one embodiment, a gate generation 
5 tool such as the gate factory or the generation tool for pre-constructed gates may be a Java-based tool to provide 
some level of platform independence. Alternatively, gate generation tools may be provided in any language, such as 
the native code for a particular device in the distributed computing environment 

Note that the distributed computing environment does not preclude a device from downloadii^ part or all 
of a gate's code. For example, in some embodiments, a service may provide gate code that may be downloaded by a 
10 client wishing to access ftat service. However, dovvrioaded code may present size, security and/^^ 

A more detailed illustration of possible gate components for one embodiment is shown in Figure 12. A 

gate may inctode its address (or name) 150, a destination gate address 152, a valid XML schema (or internal form 
thereof) 154, and a transport URI 153. In other embodiments, a gate may also include an authentication credential 
156. Some gates may also include a lease 158 and/or a message conductor 160 to verify m^age ordering. 
15 A gate's name 150 may be a unique ID that wiU (for the life of the gate) refer only to it A gate may be 

addressed using its gate name 150. In one embodiment, gate names may be generated as a combination of a string 
from an XML schema (e.g. from a service advertisement) and a random number, such as a 128-bit random number. 
The name 150 may allow clients and services to migrate about the network and still work together. Tn a prefenred 
embodiment, the gate address is independent ofthe physical message transport address and/or socket layer. Thus, a 

20 gate name may provide a virtual message endpomt address ttiat may be bound and un-bound to a message transport 
address. Inoneembodhnent,agate'snamemaybeaUniversalUniqueldentifier(UUID)thatmay,for1helifeof 

the gate, refer only to it 

A gate name may persist as long as the gate persists so that different appUcations and clients executing 
withm the same device may locate and use a particular gate repeatedly. For exan^le, a gate may be created for a 
25 first client process executing within a device to access a service. After the first cUent process has conq)leted its 
activity with the service, it may release the gate. Releasing the gate may involve un-binding the gate from the first 
client process's message transport address (e.g. IP and/or Port address). Tbe gate may be stored in a gate cache or 
repository. A second cHent process executing within the same device that desires to run the same service may locate 
fte gate by its name and use it to access the service. To use the gate, the second client process may bmd the gate to 
30 its message transport address, so that the message endpoint for the second cUent process is a combmation of the gate 
name and the second client process's transport address. In another example, a cUent may receive a dynamic IP 
address (e.g. amobUe cUent). When the client's transport address changes, a gate iwme (or gate names) may be re- 
bomid to the client's new transport address so that the cHent m^ still access a service(s) that it previously accessed 
without having to relocate the service and recreate the gate. A gate name may also be usefiil for process migration. 
35 A process and any associated gates may be checkpointed or saved at one node in the distributed computing 
enviromnent and moved to another node. The process may be restarted at the new node and the associated gates 
may be bound to the transport address for the new node so that the process wiU still have access to the external 
services to which ft had access before being migrated. A gate may track the current location of another gate to 
which it is paired. TTius a service or client may be migrated and stiU be accessible. For example, repKcated or load- 
40 balanced service implementations may be abstracted from clients ofthe service by legate. 
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Thus, a gate name 150 provides a flexible mechanism by which to address a message endpoint in the 
distributed computing environment A gate name may be used to locate and/or address a gate over a wide range of 
networks, from a local network to the Internet Gate names may be independent of message transport so that a 
message endpoint (gate) may be moved from transport to transport by unbinding and rebinding to different 
5 underlying transport addresses (e.g, IP/Port address pairs). 

In one embodunent, a gate may also be separated from a service so that the same gate may be used to send 
Inquests to different services over time. This may involve un-bmding the gate's destination gate address 152 and 
binding anew destination gate address to the gate. 

A gate may be implemented as a layer above a device's transport layer (e.g. networking sockets). Each 
10 gate may include a transport reference 153. The gate name 150 may be bound to the transport reference 153 as 
described above. Multiple gates may share the same message transport For example, multiple gates may have 
transport references 153 to tihe same TCP/IP socket By sharing the same message transport, the size and 
complexity of each gate may be reduced A device in the distributed computing environment may have a large 
number of gates that need to send and receive messages. The message handlmg complexity for multiple gates may 
15 be reduced by sharing a common message transport. The transport reference 153 may be a transport URI (e.g. 
UKL) or socket reference and may provide a mechanism for naming an underlying transport and sharing the 
transport with oAer gates. Multiple local gates may include a reference 153 to the same transport, however, each 
local gate may behave independently of tiie other local gates sending and receiving messages to and from its paired 
remote gate. 

20 The schema 154 may be downloaded from a space mto the gate by the gate fectory. The schema may be 

compiled mto an internal form suitable for quick access during a message verification process, hi one embodiment, 
the schema may specify two groups of messages: client service messages and provider service messages. The chent 
service messages group includes the description of all messages that the client may send (that the provider supports), 
and the provider service messages group includes the description of all messages tiiat the provider may send (that 

25 the client receives), hi one embodunent, either the chent or provider may send a particular request to the space 
service to obtain a response message with either: the entire chent service messages, the entire provider service 
messages, the entire client and provider service messages, or a specific message of either the chent service messages 
or the provider service messages, hi addition, once a gate has been constructed, a chent may query as to tiie 
capabilities of the service without the gate actually sending a message, but mstead by mspecting the gate's set of 

30 messages. 

As described above, a message gate may verify tiie sender of the message usmg an authentication 
credential, message content for type safety and accordmg to an XML schema. However, it may also be deshable to 
verify that messages are sent between a chent and a service in the correct order. It may be desirable to be able to 
provision apphcations (services) for clients to run without any pre-existmg specific fimctionahty related to tiie 
35 appHcation on the chent (e.g. no GUI for the apphcation on the chent). For example, a Web browser may be used 
on a chent as the GUI for a service instead of requiring an apphcation-specific GUI. Of the possible messages m the 
XML schema, the chent may need to know what message next to send to the service. It may be desirable for the 
chent to be able to determine which message to send next without requiring the cUent to have specific knowledge of 
the service, hi one embodiment, tiie service may contmuaUy send response messages indicating the next input it 



23 



wo 01/86394 PCT/USOl/15134 

needs. The service would then accept only the corresponding messages from the client with the requested input 
specified. Other ad hoc scheme for message ordering may also be employed. 

In another embodiment, a message conductor 160 may be employed in the gate or associated with the gate 
to verify the correct sequence of messages, as opposed to verifying each message's syntax (which may already be 
5 performed in the gate acoordmg to the schema). Message conductor 160 may provide a more general approach for 
application provisioning. Hie message conductor 160 may be specified in a service's advertisement The message 
conductor indication in a schema may allow code to be generated on or downloaded to the client during gate 
construction, which may provide the choreography needed to decide which message to send next to the service. A 
message conductor may be implemented as a Java application, a Java Script, WML script, or in other programming 

10 or scripting languages. 

In one embodhnent, the message conductor may accept as input an XML document (e.g. from a service 
advertisement) that presents the vaHd order or choreography for messages that may be sent between a cUent 

service. This XML document may also specify user interfece information and other rules. The conductor may parse 
tins XML document into an internal form and enforce message ordering (and/or other ides) according to the 

15 enclosed ordering infonnation. Theconductormay prevent messages from being sent out of order. Or, if a message 
is sent out of order, an exception may be rais^ within the sending device. If amessage is received out of order, the 
conductor may send an automatic response message back declaring the ordering eiror. The sender may then resend 
messages in the correct order. Note that in some embodiments, part or all of a conductor may be shared by several 
gates. Thus, a conductor may be linked to multiple gates. 

20 In one embodiment ofa distributed computing environment, front ends for semces (service interfeces)m^ 

be built in to cUents. In one embodiment the service interface may be a preconstructed nser interfece provided to 
the client by the service. In one embodiment, the service interface may be provided to the cUent m the service 
advertisement The service mterface may interact on the client with the user of the service to obtain input for 
lumiing the service, and then may display results of running the service on the client A "user" may be a human, 
25 embedded system, another client or service, etc. In one embodiment a cUent device may not be able to provision 
arbitrary services, as the client device may only be able to run services for which it has a front end built in. In one 
embodiment a service interface for a service may be implemented m a Web browser on the client 

hi one embodiment a message conductor and/or service interface may be external to the gate and thus 
abstracted from the gate and cUent The absfracted message conductor may provide provisioning of aibifrary 
30 services to any client device. In one embodiment, the message conductor may be written in code that may run on 
substantiaMy any platform. In one embodiment the message conductor may be written in the Java language. In one 
embodiment the message conductor may not require the arbitrary downloading of objects, for example. Java 
objects, returned to the client device. For example, very large objects may be returned, and the message conductor 
may choose to not download these very large objects. In one embodiment, the message conductor may send XML 
35 messages to services from the cUent device on behalf of the client n,e messagp conductor may interact with the 
user of the service to receive input anddisplayresuMs. 

In one embodiment a service interface may be provided that interacts with the cKent (e.g. thru a user 
interfece) to obtain all infohnation to run the service, and then may display either results of nmnmg the service or 
infomiation regarding the location of results, as appropriate. The service interfece may be either part of a message 
40 conductor 160 or may be in addition to and woric with message conductor 160. The service interfece may either be: 
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L Built in to the client device and thus run on the client 

2. Downloaded to the client device from the space server. 

3. Run on the space server. 

4. Run on the service provider. 

5 In one embodiment, to a cUent, the distn^uted computing environm^^ 

indicate if #2 is supported (by advertisement in space), indicate if at least one of #3 and #4 is supported. Note that 
>vhether or not it supports #4 depends upon wheto or not the service provider supports In one embodunent, to 
a service provider/the distributed computing environment space server must support #4 always and indicate if it 
supports #3. 

10 Regardless of where the service interface runs, once a service is activated, the service iaterfece may interact 

with the cUent, displaymg (reniotely) requests for input on the cUent's disp^^^^^ 
ofrmming the service. SuchintenicticHi wth the client is implemented in tenns of XML messages. 

■me service interface and/or message conductor may meet the needs of a client user that may have 
discovered a service, but does not want to read a typically large, dry computer manual to figure out how to use the 
service. As the service interfece and/or message conductor interacts with the user to request aU input that the service 
needs, they may even provide short descriptions of the mput requested if the user requests it Once the service 
mterfece has obtained the necessaiy information from the cUent, it may send X^4L messages to the sem^^ 

that runs the service. The ordering of the messages may be verified by the message conductor 160 in the gate. 

In a preferred embodiment, all messages flow through a gate. A gate may be configured to provide a flow 
20 controlmechanism. Forexample,aservicemayneedtohandlealargeamountofincomingandoutgoingme^^^^^ 
Flow control may allow a service to keep up with high traffic volume. Gates may be configured to monitor 
messages for flow control tags. When a gate receives a message, it may examme that message for a flow control tag. 
The flow control tags may be XML tags. A message may inchide either an OFF tag or an ON tag, for example. If a 
received message mcludes an OFF tag, the receivmg gate will stop sendmg messages to its paired destination gate. 
If the gate receives a message inchiding an ON tag, it may resume sending messages. 

Hius, a service-side gate may monitor flie use of its resources and trigger flow control if use of its resources 
exceeds a thiJbhold. For example, a service may reduce its load by sending messages including OFF tags to one or 
more cUent gates. The client gates receiving the messages with OFF tags will stop sendmg messages to the service. 
Pending messages m the cKents may be buffered or may be handled by internal flow control mecha^^ Oncethe 

30 service is able to handle more requests, it may send messages to one or more cUents with ON tags so that the clients 
may resume sending messages. In other embodiments, other flow control tags may be supported in addition to or 
instead of ON and OFF. Other flow control tags may indicate to reduce message flow or that message flow may be 
increased. 

Message gates may be configured to perform resource monitoring. For example, since all messages may 
35 flow through a gate, the gate may be configured to manage and/or track a client's use of a service (and possibly its 
associated resources such as memory or threads). A gate may be configured to track the activity of a software 
program, such as a cUent. by monitoring how much a resource, such as a service, is used or which and how many 
service resomces are used. In one embodiment, a gate may generate or may fecilitate generation of a cUent activity 
log. Each message and its destination or sender may be logged. 
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A gate may also be configured to perform resource monitoring for flow control from the local (sending) 
side of a gate pair. If tire client exceeds an allocated bandwidth of service (or resource) usage, the gate may. 
automatically throttle back the flow of messages, for example. Thus, a client-side message gate may automatically 
trigger different flow control modes by monitoring the flow of outgoing messages. If the outgoing message flow 
5 exceeds a threshold, the gate may reduce or shut off its flow of outgoing messages. The threshold may be specified 
in a service's XML schema or advertisement In some embodiments, the threshold may be specified only for 
messages using certain service resources or for all messages. 

The gate may also be configured to determine when message flow may be increased orresmned. In one 
embodiment, the gate may maintain a count of outgoing messages that have been sent without the matching reply 
10 (response) received. When matching responses are received by the client-side gate, the count of outstanding request 
messages may be decremented. When the counts decrements below a specified outstanding request message 
threshold, the gate may mcrease or resume sending new request messages. 

A gate may be configured to support message-based accounting and/or billing. A billing system may be 
implemented based upon the number and/or kind of messages sent and/or received by a message gate. Since all 
- 15 messages to aud from a client may pass through a gate, the gate may be configured to facilitate charging a cUent for 
service usage, for example on a per message basis or ''pay as you go". Thus, a billing system may be implemented 
within the distributed computing enviromnent in which a user could be charged, for example, each time a message is 
sent and/or received by software running on behalf of the user. 

In one embodiment, a message gate may receive billing information from an XML schema, e.g. for a 
20 service. The billing information may denote a billing policy and a charge-back URI. The charge-back URI may be 
used by the message gate to charge time or usage on behalf of a user. A message gate may make a charge-back by 
sendmg a charge message to the charge-back URI specified in the XML schema. Gates so configured may be 
referred to as bill gates. The billing policy may indicate charge amounts per message or per cumulative message 
totals, etc. Hie billing policy may indicate how much and/or how often (e.g. after every x number of messages sent 
25 and/or received) to charge the user. The policy may indicate that only certain types of messages trigger charges, 
such a messages requesting a specified service resource. The billing policy may also indicate different billing 
models for different clients or classes of clients. For example, a billing policy may be configured (e.g. in a service's 
XML schema) so that some clients may pay a one-time charge when ttiey create a gate to access the service. The 
policy may indicate clients that are to pay as they go (e.g. per message), or m^ indicate clients that are not to be 
30 chargedatall. 

In some embodiments, a client may be too thin to support a full gate, or a client may not iuclude software to 
directly participate in the distributed computing environment In such embodiments, a server (such as the space 
server in which the service is advertised or another server) may be a frill or partial proxy gate for the client The 
server may instantiate a service agent (which may include a gate) for each service to be used by the client The 

35 service agent may verify permission to send messages; send messages to the provider, possibly queuing them until 
the provider can accept the next one; send messages to the client, possibly queuing them until the client can accept 
the next one; and manage the storing of results in a result or activation space. See also the Bridging section herein. 
' For example, as illustrated in Figure 13, a client may be a conventional browser 400 that does not support 

gates to participate directly in the raessagmg scheme described above. The browser 400 may be aided by a proxy 

40 servlet (agent) 402. The browser user may use a search engine to find a Web page that fronts (displays the contents 
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of) a space advertising services within the distributed computing environment The user is able to point and click on 
the space Web page and, with the help of the servlet, to access services. The Web pages may include scripts, for 
example, Java or WML scripts, which may be used in comiecting the browser to the proxy servlet Scripts may also 
be used to send messages to the proxy servlet. The servlet agent may translate Web page actions mto messages on 
behalf of the browser client These actions may include navigating a space, starting services, and returning results. 
Result page URls (referencing pages contaming XML) may be returned dkectly (or translated mto HTML or WAP 
if needed) to the browser, for display to the user. Thus, the browser-based client does not need to know how to start 
services, nor which messages to send during the service usage session. For example, a user of a WAP browser (e.g. 
on a cell phone) may connect to a space page, browse its contents (services), and then start a service, all by pomting 
and clicking. The agent 402 provides the client interface between tiie conventional client and fhe distributed 
computing environment 

The distributed computing environment may include several different types of message gates for 
commumcating between clients and services that support different features. For exan^le, as discussed above, some 
gates may support flow control or billmg. Another type of message gate may support a form of remote method 
iavocation. This type of gate may be referred to as a method gate. 

A gate is a secure message endpomt that sends and receives type-safe messages, e.g. XML messages. The 
remote method invocation (RMI) style gate may be referred to as a method gate. The dkect data-centric gate may be 
referred to as a message gate. A method giaie may be implemented as a "layer" on top of a message gate. The exact 
implementation may be defined in the platform binding. 

Figure 14 illustrates the use of a method gate to pro^de a remote method invocation iaterface to a service. 
Method gates provide a method interfece between clients and services. A method gate may be bi-directional, 
allowing remote method invocations from client to service and finm service to client A method gate 172 may be 
generated from XML schema mformation 170 (e.g. from a service advertisement in a space). The XML schema 
mformation 170 includes XML defming a method mterface(s). From this information, code may be generated as 
part of .the gate for interfacing to one or more methods. Each method invocation (e.g. from a client application 176) 
in tiie generated code may cause a message to he sent to the service contaimng the marshaled method parameters. 
The message syntax and parameters to be included may be specified in the XML schema. Thus, the method gate 
172 provides an XML message interface to remotefy invoke a service method. The method gate may be generated 
on the chent or proxied on a server, such as the space server where the service method was advertised or a special 
gateway server. 

A service may have a corresponding method gate that implements or is hnked to a set of object methods 
that correspond to the set of method messages defined in the service's XML schema. Tliere may be a one to one 
correspondence between the object methods implemented by or linked to the service's method gate and the method 
messages defined by die service's XML schema. Once a service's corresponding method receives a message from a 
client to invoke one of the service's methods, the service's method gate may unmarshal or unpack the parameters of 
the message invocation and then mvoke the method indicated by the received message and pass the nnmarshalled 
parameters. 

The method gate may provide a synchronous request-response message mterface in which clients remotely 
call methods causing services to return results. The underlymg message passing mechanics may be completely 
hidden from the cHent This form of remote method invocation may deal widi method results as follows. Instead of 



27 



wo 01/86394 



PCT/USOl/15134 



downloading result objects (and associated classes) into the client, only a result reference or references are returned 
in XML messages, in one embodiment. An object reference 178 may be a generated code proxy (e.g. results gate) 
representing the real object result 180 (still stored out on the net, for example). In other embodiments, the client 
may choose to receive the actual result object. In addition, once a client has received a result object reference, the 
client may use this reference to receive or manipulate the actual result object In one embodiment, the result 
reference inchides one or more URIs to the real result 

The real result object(s) may be stored in a service results space (which may be created dynamically by a 
servlet, for example). This temporary results space may act as a queiy results cache. The results cache (space) may 
be patrolled by server software (garbage collector) that cleans up old result areas. Results returned from each 
method invocation may be advertised in the results space. A result itself may be or may include a method that could 
then be remotely instantiated by a client, thus generatmg its own method gate. Therefore, the distributed computing 
environment may support recursive remote method invocation. 

As mentioned above, when a client uses a method gate to remotely invoke a service method, a reference to 
the method results may be returned from the service method gate instead of the actual results. From this reference, a 
results gate may be generated to access the actual result Thus, the client or client method gate may receive a result 
URl and perhaps a result XML schema and/or authentication credential for constructing a gate to access the remote 
method results. 

In one embodiment, a service gate may create a "child gate" for the results. This child results gate may 
share the same authentication credential as its parent gate. In some embodiments, results may have a different set of 
access rights and thus may not share the same amhentication credential as its parent. For example, a payroll service 
may allow a different set of users to initiate than to read the payroll service's results (paychecks), 

A service method gate may return a child results gate to the client gate as the result of the method. The 
client may then use the results gate to access the actual results. In one embodiment, the software program (client) 
receiving the results gate cannot distinguish between the results gate and the result itself in which case the results 
gate may be an object proxy for the actual result object. The results gate may also be a method gate that supports 
remote method invocation to result objects. In this manner, a chain of parent and child method/results gates may be 
created. 

In one embodiment, the method gates and remote methods may be in Java. In this embodiment, method 
results are correctly typed according to the Java typing system. When a Java method is remotely invoked as 
described above, the results gate may be cast into the Java type that matches the result type. In tiiis embodiment, 
method gates may be used in ihe distributed computing environment to allow remote Java objects to behave as local 
Java objects. The method invocation and results may appear the same to the client Java software program whether 
the real object is local or remote. 

See the Spaces section below for a further discussion on the use of spaces for results. 

Message gates may also support publish and subscribe message passing for events. Message gates with 
event support may be referred to as event gates, A service's XML schema may mdicate a set of one or more events 
that may be published by the service. An event gate may be constructed from the XML schema. The event gate 
maybe configured to recognize some or all of the set of events published by a service, subscribe to those events, and 
distribute each event as the event is produced by the service. 
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The set of events for a service may be described in the service's XML message schema. For each event 
message in the XML schema, the event gate may subscribe itself as a consumer of that event In one embodiment, 
an event gate subscribes to all events indicated by the XML schema. Each event message may be named using an 
XML tag. The event gate may subscribe by sending a subscription message mcludmg the XML tag for the event to 
5 be subscribed to. 

When a coirespondmg event occurs with the service, the service may send an event message to subscribers 
indicatmg the occurrence of the event. Tlie event message may contain an XML event document and may be sent to 
each subscribed gate. When a subscribed gate receives the event message, the XML event document is removed 
from the message and the process of distribution begins. Event distribution is the process of handuig out the event 

10 document withm the client platform. Each event consumer withm the cUent platform may subscribe with the event 
gate for each type of event On Java platforms, the typing system is Java (converted from^ 

The event consumer may supply an event handler callback method to ftie event gate. The event gate may 
store a list of these subscriptions. As each event message arrives at the gate (from the service producing the event), 
the gate traverses the list of cUent consumers and calls each handler method, passing the XML event document as a 

15 parameter. In one embodiment, the XML event document is the only parameter passed to the handler callback 
me&od 

In one embodiment the event gate automatically subscribes itself for events on behalf of the local consumer 
cHents. As clients register interest with the gate, the gate registers mterest with the event producer service. A client 
may also un-subscribe mterest which causes the gate to un-register itself with the service producing the event 
20 An event gate may type check the event document using the XML schema just like a regular message gate 

does in the standard request-response message passmg style described above. An event gate may also mclude an 
authentication credential in messages it sends and verify the authentication credentials of received event messages. 

Note that any combination of the gate fimctionality described above may be supported in a single gate. 
Each type has been described separately only for clarity. For example, a gate may be a message gate, a method gate 
25 and an event gate, and may support flow control and resource monitoring 

Service Discovery Mechanisms 

In one embodiment the distributed computmg environment may include a service discovery mechanism 
that provides methods for cUents to find services and to negotiate the rights to use some or all of a service's 
30 CE^abilities. Note fliat a space is an example of a service. The service discovery mechanism may be secure, and 
may track and match outgomg client requests with incoming service responses. 

A service discovery mechanism may provide various capabilities including, but not limited to: 

• Finding a service using flexible search criteria. 

• Requesting an authori2ation mechanism, for example, an authentication credent^ 

35 client the right to use the entire set or a subset of the entire set of a service's capabilities. 

• Requesting a credential, document or other object that may convey to the cHent the settee's mterfece. In 
one embodiment, the service's interface may include interfeces to a requested set of the service's 
capabilities. 
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• The tracking of discovery responses to the original requests. In one emboxiiment, each client request may 
include a collection of data that may also be returned in matching responses/Uius allowmg the requests and 
responses to be correlated. 

In one embodiment of the distributed computmg environment, a service discovery mechanism may provide 
a fle^ble search criteria based npon an extensible grammar, in one embodiment, a service name, service type, mid 
other elements, if any, being searched for may be matched with elements in an XML document In one embodunent, 
the XML document is the service advertisement for the service. XML may provide a flexible, extensible grammar 
for searching. XML also may provide type safety for matching elements. In one embodiment, the service names 
and service types may be type checked witii the element types in the XML service advertisement 

In one embodhnent, a distributed computing environment may iuclude a mechanism for clients to negotiate 
service access rights. In one embodiment, the mechanism may be used to negotiate for a subset of a service's fiill 
capabilities. The result of the negotiation may be an auttiorization such as an authentication credential that conveys 
to the client the right to use the requested subset of the service's capabilities. 

In one embodiment, the service discovery mechanism may allow a client to request a security capability 
credential from a service. In one embodunent, tiie client may present to the service a set of desired capabilities in 
the form of a protected (secure) advertisement The service may then respond with a c^ability credential that may 
convey to the client the ri^ts to use the requested capabilities described in tihe protected advertisement 

In one embodunent, the distributed computing envnonment may include a mechanism for a client to 
negotiate service access rights and to then obtain a security credential or document that may be used to present the 
service's access interface to the set or subset of the service's capabilities that were requested by the client 

In one embodiment, a client that receives a capability credential from a service may generate a custom 
service access interfece document that may be referred to as a "complete advertisement" In one embodiment, the 
complete advertisement may be an XML document The generated advertisement may provide access to tiie service 
capabiHties as granted to the client by tiie received capability credentiaL In one embodiment, an interface may be 
provided by the advertisement only to the service capabilities to which the client has been granted access by the 
capability credentiaL In one embodiment, the client may be granted access to only required c^abilities and to 
which the client has access privileges. 

In one embodiment, the distributed computing enXoronment may provide a mechanism by which a client 
may negotiate capabiUties witii services. In one embodiment, the client may negotiate its c^abihties to the service. 
The service may then customize results based on the parameters negotiated with the cUent For exan^)le, a client 
that is capable of one bit display at a resolution of 160x200 may negotiate these parameters to tiie service, tiius 
allowing the service to customize results for the client 

The following is included as an example of an XML capabilities message and is not intended to be limiting 

in any way: 

<type name=*'Capabilities"> 

<elementname="display" type="string"/> 
<elementnaroe=="memory" ^e=-"string"/> 
<elementname="mime" type="string"/> 



30 



WOOl/86394 

</type> 



pCT/USOl/15134 



The distributed computing environment may include a mec^ 
service is to return results of a service invocation. In one embodiment, during a capability credential request, a 
5 means by which to choose one of the results return methods may be conveyed to tbe service. Tl^e service may then 
generate a custom service advertisement that may convey to the client the results mechanism to be used, as well as 
the service interface. 

Thus, the service discovery protocol may allow clients to search for services (both space services and 
specific services or types of services). Service providers (or a listener agent) may respond to search requests by 
10 publishing or providing corresponding advertisements or URfc to coiresponding advertisements. When a service 
provider responds to a discovery search request (either directly or through a fe^^ 

to pubUsh a protected or an un-protected (complete) advertisement A protected advertisement may mclude the set 
of information necessary to obtain a complete advertisement Publishing a protected advertisement forces the client 
to obtain a vaUd credential from an authentication service before receiving the complete un-protected advertisement 
15 from the service provider. A complete un-protected advertisement is needed to create a gate, and therefore to use 
the service. Forcing cUents to obtain a valid credential before receivmg an advertisement may provide an additional 
level of security for the service provider. The security credential thi must be obtained to receive the complete 
advertisement may be the same security credential that is used to construct a gate to communicate with the service 
where the gate embeds the security credential in each message to the service. 
20 Whether or not a service provider publishes a protected or complete advertisement may be based upon the 

service provider's desired level of security. Complete advertisements contain the service's message endpoint URL 
Concealing this address may be a desfrable security feature m many kinds of networks and deployment 
enviromnents. However, simple proximity networks hke IRDA, vahdate ch^^^ 

proximity to the service provider. Concealing the IRDA message address from a close proximity cHent may just be 
25 redundant or too burdensome, hi either case, the discovery search response choice may be left to the service 
provider. In a preferred embodiment, clients (or cHent gate factories) are configured to process either search 
response. 

Tunung now to Fig. 41, a flow chart illustrating service discovery is illustrated according to one 
embodiment A cUent locates one or more advertisements for service(s) the cHent may desire to use, as indicated at 
30 2072. In one embodiment, the client may locate services by sending a search message. Turmng now to Fig. 42, a 
flow chart illustrating a more detailed example of locating service advertisements is iUustrated for one raabodhnent 
The chent may send (e.g. broadcast, multicast, etc.) a search message indicating service name and/or ser>dce type 
search criteria, as indicated at 2071. 

The followmg is aa example for one embodiment of a search mess^e that may be sent on one or more 
35 available message transports when a chent wishes to search for services: 

<Discover> 
<Search> 

• <SearchType> Type</SearchType> 

40 <SearchName>Name<SearchName> 
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<SearchConnnen1^ Comment</SearchCommenl> 

<7Search> 
<;/Discover> 

5 The seazch message is fomatted according to a data representational language. He search and discovery 

tags be .«iuired. TTae search tags rm contain an optional set of search criteria, useful for nam>wi„g the 
possible results returned from service provider. Tte optional search criteria components may include a name (e.g. 
String) Thenameiscompar^dvrithaservice-sname. Ifthesearchnamematchesthebeginningorallofihe 
service'sname,amatchrnaybedeclaredforthatservice.Moneembodiment,ifthenamei^ 

10 names are considered a match. 

Tie optiond search criteria component may also include a type (e.g. string). Tl«^ 

the service type. e.g. in the service description's 'T:itle" Md. If the search type m^^^ 

service's type, a match may be declared. In one embodiment, if the type isn't provided, all service types are 
considered a match. For example, the type string n«y be >ace" ,vhen operating on a lai^e netwc«k or "s^^ 
15 when operating in a proximity network. Additional levek of type may be employed. 

Th„sasindicatedat2072mFig.42.theservicenameand/orservicetypesean=hcriteri^ 
tonameandtypeinfonnationforservices^thinthedistn^utedcomp«th«e.n^ Each service provider that 
receives the search message may perform this comparison. Or a listener agent may perform tte comparison for 
services registered with the listener agent. 
20 The optional search criteria components may also mclude a comment (e.g. String). Ihe comment stnng 

m.y be returned in the body of the response message, and may be a useM discovery message trackmg tooL For 
example, a timestamp might be a usefijl comment string. 

A search response may then be i^ed to the cUent indicating advertisements for services that match the 
search criteria. The foUowmg is an example for one embodiment of a service provider response message that may 
25 besent(e.g.unicaslDbyaserviceproviderinresponsetothesearchmessage: 

<Discover> 

<SearcliResponse> 

<SearchCoinment> Comment String</SearchCommen1> 

30 <Advertisement>Advertisementl<^Advertisement> 

<Advertisement> Advertisement2 </Advertisemen£> 

<Advertisement> Advertisemenm ^/Advertisement^ 

</SearchResponse> 
</Discover> 

The response message may include tiie set of advertisements that match the search criteria, hi one 
embodhnenVif fl.e search M weren't suppUed, aU available advertisements are defined as amatch. to one 
er-jbodhnent. if a comment string ^ supplied, the response also contams that same comment, possibly an 
additional comment appended to the end of the original string. 
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As mentioned above, a service may publish either a protected advertisement or a complete advertisement 
Thus the advertisements indicated in a response to a search may be protected or complete advertisements. A 
protected advertisement may not indicate the actual URI or schema that may be used to access the service. Instead, 
a protected advertisement may contam information on how to obtain a complete advertisement that includes the URI 
5 and schema to access some or all of a service's capabilities. In one embodiment, a protected advertisement may 
include the following information: 

• Name and type of Ihe service. 

• Capability descriptions of file service. 

• UUIP of the service. 

10 • UWofauaentication service, which win letum a suitable cUent access (cq>ability)creden 

• URI where Recredential and UUro may be sent to gCTerate a complete service advertbeme^^ 

A protected advertisement may be a smaller, surrogate XML document fiagment (a meta^vertisement). 
A protected advertisement may provide a level of mdirection between the client and the i«al advertisement, 
requiring the cHent to negotiate for access to the real advertisement Publishing a protected advertisement instead of 
15 a complete advertisement forces the cUent to obtain a valid credential from an authentication service before 
receiving the complete un-protected advertisement from the service provider. 

Returning to Fig. 41, after fee client receives a response to it s search, it taay select one of tiie 
advertisements for one of the services for which it wishes to negotiate access by requesting a capabflily credential, 
as indicated at 2074. This advertisement negotiation process may provide additional security in fte distributed 
20 computing enviromnent (e.g. by hiding real advertisements), while at the same time adding some flexibility. For 
example, during the advertisement negotiation process, a client m^ request a custom set of messages for accessing 
the service. Tbe client may provide the desired name and type of interface. One example of requesting a custom set 
of messages may be requesting only "read" access as opposed to "read" and "write" access to a service. When 
requesting a custom message set, the client may wish to only use a subset of the service's fiOi capabilities 
25 (messages). The right to use flie requested set of messages may be verified during the negotiation. If lhe cUent 
doesn't have the proper access rights to the requested capabilities, the negotiation fafls, otherwise a valid credential 
is retumed to the client 

A cUent may also request additional access message sets. Client may provide the desired name and type of 
inter&ce. Some clients may require the use of more than just the base access messages. A cUentmay request a set 
30 of additional access messages. Some of these access messages may even address platfonn spedfic issues such as 
perfonnance and memory fooq)rint size. 

A client may also request that a non-XML content type be used to represent data passed in flie messages 
between client and service. Some clients m^ not support XML, but still wish to access services witiiin Ae 
distributed computing enyiromneat To allow non-XML clients access to services, non-XML content may be 
35 tumieled within an XML message. Tie non-XML content may be wrapped by an XML tag on the sending side, and 

then extracted on the receivmg side. 

Service providers may benefit from the use of protected advertisements in several ways. As already 
mentioned, protected advertisements prevent unauthorized clients from receiving complete advertisements, and 
allow capability negotiation. Protected advertisements may also allow for dynamic advertisement generation. When 
40 a client negotiates for a complete advertisement, an opportunity to generate a custom one "on the fly" exists. TTiis 
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feature aUows smaller XML document fragments to be downloaded to cHents since the complete advertisement need 
be only as big as requested. This feature also allows a service to effectively publish advertisements specific to cUent 
requirements. 

Protected advertisements may also feciUtate service queries. Protected advertisements may be published 

instead of complete advertisements to feciUtate dynamic searches for services that match the client requested set of 

capabilities. Protected advertisements may indicate a service's capabOities in a searchable format without including 

a complete message schema for those facilities. 

In one embodiment, a protected advertisement may include the foUowing ™L document elements: 

• Name (Human readable, non-canonical string) 

• Canonical name of service (e.g. UUID) 

• Base Metiiodlnterfece Description (Message Interfece Description) 

-Tide (Message interfece standard name that conveys a type) 

- Provider Name (Standards Body Kame) 

- Version (Version of standard (type) implemented) 

- Info URI (Standard body's web page) 

• Additional Access Method hiterfece Descriptions 

- List of descriptions containmg: Title, Provider, Version, Info URI- 

• Content Type Descriptions 

"List of descriptions containing: Title, Provider, Version, Info URI. 

• Credential 

- Service's credential to enable client to autiienticate service 

• Authentication UKI 

- A message may be sent here to obtam a suitable credential that grants access to this service. 

• Generate Real Advertisement URI 

- A message may be sent here to generate a complete advertisement, given a protected advertisement 
that contains the client's requested capabilities. 

To obtam a complete advertisement, given a protected advertisement, a client (e.g. client's gate fectory) 
obtains a capability credential from the specified autiientication service by sending a credential request message, as 
indicated at 2074 in Fig. 41, The credential request message may be sent to an authenticated service URI specified 
m the advertisement for the service the client desires to access. When the client's request is received, a capability 
credential is generated, as indicated at 2075. The capabiUty credential may be generated according to capabilities 
requested by the client and/or the client's level of authorization. The client then receives the capability credential in 
response to its request, as indicated at 2076. The response may contain ftie credential needed to generate tfxe 
complete advertisement This credential may be the same credential that the cUent's gate mcludes in each message 
sent to the service. 

If the advertisement was a protected advertisement, tibe client tiien may send an advertisement request 
message containmg the capability credential and an identification (e.g. UUID) of the service to the second URI 
specified in the protected advertisement, as mdicated at 2078. The client then receives a complete advertisement, as 
indicated at 2080. The response to this second message is the complete advertisement of the specified service. If 
the advertisement indicated m the credential request was akeady a complete advertisement, 2078 and 2080 may be 
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skipped Figure 43 compares the difference in tiie discover process when the published adv^isement is a complete 
advertisement versus a protected advertisement Returning to Fig. 42, a complete advertisement and the capabUity 
credential may then be used to create a gate, as indicated at 2082. 

An example of a credential request message according to one embodiment is as follows: 

5 ' 

<Discover> 
<CredentialRequest> 

<IJUID> uuid<UUID> 

<AdvertisementXIRI>adv uri</AdvertisementURI> 
10 <protectedAdvertisement>adv</ProtectedAdvertisement> 

</CredentialRequest> 
</Discovar> 

The credential request message may mclude an identification (e.g. lJUlD) of service to which access is 
15 desired. The credential request message may also include an advertisement URI referencing the advertisement or 
tiie advertisement (by value). The Advertisement may be passed by vake or by reference during this negotiation 
prtKcss. Advertisements may be complete or protected. If the advertisement passed in the credential request 
message is already a complete advertisement (e.g. service returned it in tiie search response), then the credential 
returned from the service will aUow access to all of the service's capabilities (aU access methods + all messages). 
20 A protected advertisement may be edited to contain just tiie desired set of access method and content 

descriptions. The edited protected advertisement may be passed m the credential request message. Thus, a client 
may build and expresses its set of requested capabilities by editing the advertisement, or copying the relevant 
information from the original to a new instance. 

An example of a credential request response message according to one embodiment is as foUows: 

25 

<Discover> 

<CredentialRequestResponse> 

<Credential>capabilitycredentiaKCredential> 

<yCredentialRequestResponse> 

30 <;/Discover> 

If the client has proper autiiorization, the credential request response message includes a capability 
credential giving the client requested access to the specified service (e.g. identified by UUID), includmg the set of 
capabihties defined in the protected advertisement This credential may then be stored in Ae chent's gate and then 
35 added to eadi message sent to tiie service. The service tiien uses this credential to vmfy tiie cUent's ri^t to use a 
service's capabilities. 

The capabflity credential structure and contents may be defined by the service. In one embodiment, tixe 
credential at least inchides a reference to the protected advertisement used during tiie negotiation, and a security key 
• to validate the client's identity. If tiie advertisement passed in tiie credential request message is aheady a conq)lete 
40 advertisement (e.g. service returned it in tiie search response), then tiie credential returned fi-om tiie service wUl 
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allow access to all of the service's capabilities. If the service provider doesn't support or require credentials at all, 
the response message may contam an empty credential (nuD). 

In some embodiments, a capability credential may be used to support the notion of sessions. A service 
provider may embed a session ID within the credential, and be sure that the client gate will pass it (credential 
5 containing ID) to the service provider m each message. The entire credential may be defined by the service provider 
and hence may contain any number of fields, including a sessionID, or other demuxing IDs, etc. 

An example of an advertisement request message according to one embodiment is as follows; 

<Discover> , 
10 <AdvertisementRequest> 

<Credential> capability credential</<>edentia> 
</AdvertisementRcquest> 
</Disc6ver> 

15 The advertisement request message mciudes the credential from the credential request response message. 

In one embodiment, this credential includes enou^ information to identify the original protected advertisement 

An exanq)le of an advertisement request response message according to one embodiment is as follows: 

20 <Discover> 

<AdvertisementRequestResponse> 

<Advertisement> CompleteAdvertisementl </Advertisement> 
</AdvertisementRequestResponse> 
</Discover> 

25 

The advertisement request response message includes the complete advertisement referenced by the 
(edited) protected advertisement Note that the credential found in the complete advertisement may be the gate 
credential to be passed in every message. 

Spaces are implemented by services of type space. Discovering a space may be accomplished eiUier by 
30 specifying the "space" type in the search criteria, or by parsing tiie set of search results, and then extractmg all 
"space'* advertisements. Spaces may be populated with advertisements (protected or unprotected) using the above 
described discovery protocol. The population may be initiated by the space service itsel£ or by another network 
service agent 

Once a space is discovered, its contents may be examined using standard space service navigation 
35 messages or as defined in the space service advertisement For each advertisement within the space, a client gate 
factory may build a gate (using the credential and advertisement request messages) to access the named service. 

Xn oiie embodiment, all advertisements (protected and complete) contain a service credential. Clients msy 
validate this credential before requesting a cHent capability credential This procedure may prevent un-authorized 
services froin pubUshmg advertisements using the discovery protocoL 
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For one discovery protocol implementation example, the protocol may be bn the wire data format, which 
may be implemented in many different ways depending on tiie transport beneath it The discovery protocol 
implementation may be defined in a platfonn bindmg. For example, a possible IP implementation may be one in 
which space services Usten for UDP multicasts of space search messages. A client/service may multicast a space 
5 search message and waits for a response. Space services may unicast a space search response message contaming an 
advertisement 

In one embodiment, the distributed computmg envkonment may kclude a mechanism for track^^ 
discovery search requests and responses to the requests. In one embodiment, search request and response messages 
may include a field that may be used to include a string or an XML document hi one embodhnent, the strmg or 
10 XML document mcluded in the field of a request message is also returned in the response message. In one 
embodiment, die string or XML document is required to be rehimed 

the string or XML document may include additional information inserted in or appended to tfie string or document 
when returned m response message. In one embodhnent, this mechanism may be used in debuggmg complex 
systems. In one embodiment, this mechanism may also provide to clients a method for choosmg services to access 
15 by using the string or XML document to pass custom search mformation between a cHent and service that may only 

be understood by tiie client and service. 

For an example of fields in request and response messages, refer to the SearchCommert 

and search response messages described above. 

For some devices that provide a service, the overhead of findmg a space to advertise its service and 
20 maintain that advertisement is undesirable, hi one embodiment, rather than searchmg for and maintaming a space or 
spaces to pubUsh service advertisements, services on some devices may transmit then: advertisements in response to 
connection requests. For example, a printer device with .a printer service that is available on a proxunity basis may 
not mamtain an advertisement m a space (on the device or external to tiie device), histead, when another device 
estabUshes a connection with the printer device (for example, a user with a laptop rumung a chent deshes to print a 
25 document), the prmter service may transmit the service advertisement to provide the XML service schema for 
connecting to and running the service that provides printing functionality on the printer device. Also, some devices 
may only maintam advertisements for their services in a certain vicmity or local network. Such a device may not 
desire to support or may not have access to transports for broader accessibility. 

One example of a service device in which it may be desirable for the device to avoid or Umit mamtainmg 
30 service advertisements m a space is a device whose fimctionality is available on a proxhnity basis. Proxhnit5^-based 
services may provide advertisements of their fimctionality upon request These advertisements may not be broadly 
accessible. For example, proxhnity-based services may be provided m a wheless communications system. Hie term 
^Nvireless*' may refer to a communications, monitoring, or control system in which electromagnetic or acoustic 
waves car^ a signal through atmospheric space ratiier than along a wire. In most wireless systems, radio firequency 
35 (RF) or infrared QK) waves are used. Typically, m proximity-based wireless systems, a device comprismg a 
transceiver must be vrithm range (proximity) of another device to establish and mamtam a communications channeL 
A device may be a hub to connect other devices to a wkeless Local Area Network (LAN). 

As mentioned, embodknents of the distributed computing envux)nment may provide a mechanism usmg one 
or more spaces that aUow cHents to rendezvous with services. > a proxunity computing envhonment, one 
40 embodiment of the dishibuted computing environment may provide a service discovery mechanism that clients may 
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use to discover services without using spaces as rendezvous points. An example of a proximity computing 
environment is an IrDA point-to-point communications environment In a proximity computing environment, the - 
proximity mechanism may find the "physical" location of the service for the client For example, in an IrDA 
environment, the client device may be physically pointed at the device including the service(s) that the client desires 
5 to use. 

In some situations a client may have physically discovered the device that contains services the client 
desires to run. For example, a person with a PDA client may be in close proximity to a printer participating within 
Re distributed computing environment Various scenarios may emerge with close proximity devices. When clients 
are in close proximity to devices (e.g. publishing services), much of the dis^^^ In 
10 these cases, the user may select the device. For exainple, IRDA devices are pomted at each other to establish a 
discover connection. 

Close proximity devices for which security isn't an issue (hke an IRDA printer) may publish complete 
advertisements. Instead of enc^sulatmg services in spaces, close proxunity devices may directly respond to the 
discovery protocol. 

15 Close proxhnity devices for whidi securi^ is an issue (e.g. an ATM) may respond to discover requests 

with protected space advertilsem^ts. The space may cont^ all the services si^rted by tiie device. Once access 
to the space has been granted, clients may browse complete advertisements stored in the space. This model 
presumes that all services stored m the space can leverage the space security model, and not provide a separate 
model. Alternatively, close proximity devices for which security is an issue may respond to discover requests with 
20 protected advertisements for each service. Each service may provide its own authentication service. Combinations 
of each proximity device scenario are also contemplated. 

The proximity service discovery mechanism may enable the cUent to directly look for service 
advertisements rather than sending a search request to a space to look for service advertisements. Smce the cHent 
device may have established a proximity connection to the service device, the chent may directly request the desired 
25 service. For example, a FDA client device may establish a proximity connection to a printer device; the client may 
"knoV to request a printer service cormection on the printer device. 

In one embodiment, the cUent may send a proximity service discovery message to the service device. The 
message may mclude mformation that may specify a desired service on the service device to which the client device 
has a proximity connection. In one embodiment, a service on die service device may respond to the proximity 
30 service discovery message, and may send to the client the service advertisement that the cUent may use to conneet to 
the desired service. The proximity service discovery message may also include information that may be used to 
authenticate the client and to establish the client's capabUities on the service. Using the received service 
advertisement, the client may establish a gate to establish communication with the desured service. 

An example of a system in \^iiich a client device directly discovers a service on a service device over a 
35 proximity liiJc is illustrated in Fig. 44. A client device 2150 includes a proximity port (e.g. an IrDA port) 2156 
configured to form a direct pomt-to-pomt communication link, or proxhnity Imk. Client device 2150 may include a 
client 2152 that may desu-e to use a service over the proxhnity Imk, The cUent 2150 may be an appHcation or a 
combination of circuitry and software. A chent interface 2154 may be configured to directly request over the 
proximity Imk a document that describes an mterface to access a desked service. The mterface 2154 may also be 
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configured to receive such a document directly over the point-to-point communication link and use the information 
from the document to access the service, such as by constructing a gate. 

A service device 2170 may include a proximity port 2172 and may form a proximity Unk with client device 
2150. The service device 2170 may include code and/or hardvrare to implement one or more services 2176. 
Service device 2178 may also be configured to provide one or more documents 2178, or advertisements, over the 
proximity link. An advertisement 2178 may describe a message schema for accessing a service 2176 provided by 
service device 2170. A service interface 2174 may be configured to receive over the proximity link a request from a 
client for a document 2178 that describes an interfece to access a service 2176. The interfece 2174 may also be 
configured to provide document directly to a chent over the proximity link and provide a message endpoint (e.g. 
gale) for communicating with a client The service interfece may also provide a mechanism to authenticate clients' 
requests to access the service. 

Figure 45 illustrates a basic flow diagram iUustrating client discovery of a proximity service, A client may 
form a proximity connection to a service device, as indicated at 2190. For example, a client device may be a 
personal digital assistant (PDA) with an address book cUent The client my need to print a portion of the address 
book. The PDA may include an IrDA port and may be in proximity of a printer with an IrDA port The client may 
establish a proximity cormection to the printer. The cUent may then, as indicated at 2192, request a service 
advertisement over the proximity connection, such as a printer service advertisement Then client may then receive 
an advertisement matching its request, as mdicated at 2194. The advertisement may be received directly fix)m the 
service device over the proximity connection. The client may then construct a gate according to the advertisement 
to access the service, as indicated at 2196. 

Thus, proximity devices may avoid the overhead of usmg spaces as a rendezvous point for cMents 
discovering services. Nevertheless, it may still be deshable to publish advertisements for services (e.g. proximity- 
based services) that do not desire to or caimot maintain their advertisements in a space tihat is broadty accessible. In 
one embodiment of a distributed computing environment, a device that establishes a connection with a device that 
does not pubUsh its service advertisement(s), such as a proximity-based device, may pubHsh service advertisements 
received fix>m the non-pnblisMng device. For example, a device that establishes a connection with a proxhnity- 
based device and that has an alternate transport connection(s) may publish (or republish) service advertisements 
received from the proximity-based device in the alternate transport environment, thus allowing the proximity-based 
device service(s) to be used by other devices (through the (re)published service advertisements) which are outside 
the normal proximity range of the device. 

The publishing device may locate a locally published service advertisement for the proximity-based device 
through a discovery and/or lookup service, or alternatively the s^ice advertisement may not be published by the 
local service device, but mstead may be sent to the pubUdiing device by the local device upon the establishment of a 
proxmiity connection, as described above, hi one embodiment, the republished service advertisement may be made 
available as long as the device maintaining tiie advertisement is connected to or able to connect to frie local device. 
For example, if the publishing device is disconnected from the local device (for example, moves out of proxmiity 
range of the device), the service advertisement may be made stale or removed. A lease mechanism may be provided 
to allow the space containing the adverti§ement to send lease renewal messages to the publishing device. The 
publishmg device may veriJfy its connection to the local device, thus allowing the space to detect when the local 
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device is no longer available. Rules for how the service advertisements are republished may be provided by the 
local device or by an administrative policy for the local vicinity (e.g. proximity area) or local network- 
Figure 24 illustrates an example of a device bridging proximity-based devices onto another transport 
mechanism to allow the services provided by the proximity-based devices to be accessed by devices outside the 
5 proximity range of the devices, according to one embodhnent. A publishing device 1404 may be connected to a 
network 1412, such as an Ethernet LAN or the hitemet, etc., and may establish and mamtain proximity connections 
1414 with proxunity devices 1400 and 1404. Proximity connections may be wireless connections or wbred LAN 
connections, for example. Proximity devices 1400 and 1402 may each send a service advertisement to the 
publishing device 1404 upon connection, or, alternatively, the publishing device may locate the service 
10 advertisements using a discovery and/or lookup service for tiie proximity connections. The publishmg device 1404 
TBSsy dien make tibie services provided by the proxunity devices available to other devices 1408 and 1410 on the 
network 1412 by republishing the service advertisements 1416 and 1418 in space 1406. Space 1406 may be stored 
on the publishing device or on other devices connected to tiie LAN (including devices 1408 and 1410). 

Other devices on the LAN including devices 1408 and 1410 may then discover space 1406 and look up the 
15 republished service advertisements 1416 and 1418 for the proxioaity-based devices, establish gates to communicate 
to those services (device 1404 may act as a proxy ot bridge) on the proximity-based dewes 1400 and 1402 using 
XML message passing methods described previously, and send requests and receive* resuhs to the proximity 
devices. Publishing device 1404 may act as a bridge between the networic 1412 and the proximity connections 1414 
to the proximity-based devices. 



20 



Matching Component (Service) Interfaces 

The distributed computing envhonment may provide a mechanism for matching a component (for example, 
a service) specification interfece with a requested interface. For example, a client (which may be a service) may 
desire a service that meets a set of interface requirements. Each component may have a description of the mterfece 
25 to which it conforms. The specification interface matching mechanism may allow a component that best matches a 
requestor's interface requurements to be located. The specification interface matchmg mechanism may also allow 
for "fiizzy" matching of interface requirements. In other words, the mechanism may allow matching without 
requiring the exact specification of all aspects of the interface, thus providing a nearest match (fiizzy) mechanism, 
hi one embodhnent, the specification mterfece matchmg mechanism may be implemented as a multi-level, sub- 
30 classmg model rather than requhing specification at a single interface level 

In one embodhnent, a component may use an XML Schema Definition Language (XSDL) to describe its 
interface. XSDL may provide a human-inteipretable language for describing the interface, sunplifying activities 
requiring human mtervention such as debugging. In one embodhnent, the mterface desCTiption may be provided as 
part of an advertisement (for example, a service advertisement) as described ebewhere m fbis document 
35 Usmg the specification mterface matchmg mechanism, a basic deshed mterface may be compared to a set 

of con^onenf mterface descriptions. One or more components matchmg the basic deshed mterface may be 
identified. The mterfece descriptions may mclude subclass descriptions describmg more specifically die mterfeces 
provided by the components, hi the search process, the class type hierarchy m^ be exammed to determme if a 
given class is a subclass of the search type, hi one embodiment, subclasses may inherit properties of the base class, 
40 and thus the subclass-specific mfoimation may not be examined m this phase. Thus, the search may be performed 
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genericaUy. The identified components may be searched at the next (subclass) level. The search may become 
specific to the subclass and may be performed by interpreting the subclass information included in the interface 
description. The search may continue through one or more subclasses until one or more components is determined 
\n^ch may provide the nearest match to the requestor's desired interface. 
5 In one embodiment, an interface matching mechanism may provide the ability to distinguish among two or 

more components that unplement similar interfeces. In one embodiment, the interface matching mechanism may 
provide the ability to distinguish among different revisions of the same component 

In one embodiment, a component description may be provided that includes a specification of the interface 
to which the component conforms. The component description may also include information about the component 
10 itself. The interface description mid/or tiie component information may be used to differentiate arnong different 
implementations of a ^ven interfece. The component descriptions may mclude a canonical identifier and version 
information. The version information may aUow component revisions to be distinguished. In one embodnnent, the 
component description may be provided as part of an advertisement (for example, a service advertisement) as 
described elsewhere in this document 
15 In one embodiment, components may be searched for a particular canonical identifier. Two or more 

components may be identified with matching canonical identifiers. One or more components may be selected from 
among die components with matching canonical identifiers. The selection procedure may use an interfece 
specification version, a component implementation specification, a component miplementation specification version, 
other mformation or a combination of information fi-om the component description to produce a set of one or more 
20 components that best match the requestor's requirements. 

Spaces 

As mentioned above, the distributed computing environment relies on spaces to provide a rendezvous 
mechanism that brokers services or content to cHents. Figure 15 ifiustrates the basic use of a space 114. Service 
25 providers may advertise services in a space 114. Clients 110 may find the advertisements m a space 1 14 and use the 
information from an advertisement to access a service usmg the XML messaging mechanism of die distributed 
computing environment Many spaces may exist, each containing XML advertisements tiiat describe services or 
content Thus, a space may be a repository of XML advertisements of services and/or XML data, which may be raw 
data or advertisements for data, such as results. 
30 A space itself is a service. Like any service, a space has an advertisement, which a chent of tiie space must 

first obtam in order to be able to run that space service. A space's own advertisement may mclude an XML schema, 
a credential or credentials, and a URI which indicate how to access the space. A client may construct a gate from a 
space service's advertisement in order to access the space. A cheat of a space may itself be a service provider 
seeking to advertise mdiat space or modify an existing advertisement Oraclient of a space may be an application 
35 seekmg to access a service or content listed by tiie space. Thus, spaces may provide catalysts for the interaction 
between clients and services in the distributed computing environment 

A space may be a collection of named advertisements. In one embodiment, naming an advertisement is tiie 
process of associating a name string with an advertisement The association m^ take place upon storing an 
advertisement in a space. Removing an advertisement "from a space disassociates the name fix)m the advertisement 
40 A space may be created with a single root advertisement that describes the space itself. Additional advertisements 
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may be added to a space. An advertisement's name may locate the advertisement within the space, including 
specifying any necessary graphing information such as a hierarchy of names. In a preferred embodiment, the 
distributed computing environment does not dictate the structure of a space. That is, spaces may be structured as, 
for example, a flat im-related set of advertisements or a graph of related advertisements (e.g. commercial database). 
Since, in a preferred embodiment, the distributed computing envkonment does not dictate how a space actually 
stores its content, spaces may be supported by small to large devices. For example, a simple space may be tailored 
to fit on small devices, such as PDAs. More advanced spaces may be inq)lemented on large severs employing large 
commercial databases. 

As mentioned above, a space may contam advertisements for services in the distributed computing 
enviroranent An advertisement may provide a mechanism for addressing and accessing services and/or content 
within the distributed computmg environment An advertisement msy specify a UKI fa: a service. In some 
embodiments, the URI may allow for the service to be accessible over the Internet An advertisement may also 
include an XML schema for the service. Hie XML schema may specify a set of messages that clients of the service 
may send to the service to invoke fimctionality of the service. The XML schema may define the client-service 
interface. Together, the URI and the XML specified m an advertisement may indicate how to address and access the 
service. Both the UKI and schema may be provided in XML as an advertisement in a space. Thus, a mechanism for 
addressing and accessing a service in a distributed computing environment may be published as an advertisement in 
a space. Clients may discover a space and then lookup individual advertisement for services or content 

Figure 16 illustrates advertisement structure accordmg to one embodiment An advertisement 500, like 
other XML documents, may include a series of hierarchically arranged elements 502. Each element 502 may 
include its data or additional elements. An element may also have attributes 504. Attributes may be name-value 
string pairs. Attributes may store meta-data, which may facilitate describing the data within the element 

In some embodiments, an advertisement may exist in different distinct states. One such state may be a 
drafted state. In one embodiment, advertisements may initially be constructed in a drafted state that exists outside 
the bounds of a space. The creator of an advertisement may construct it in a variety of ways, including using an 
XML editor. Access to elements and attributes hi the drafted state may be at the raw data and meta-data levels usmg 
any suitable means. Typically, events are not produced for changes made to advertisements in the drafted state. 
Therefore, the creator of the advertisement may be free to add, change, or delete elements as well as to achieve the 
desired attribute set, and then publish the advertisement for the rest of the distributed computing environment to see. 
In one embodiment another possible state for advertisements is a published state. Advertisements m^ 
move to the published state when inserted into a space. Once the advertisement is in a space, interested clients, and 
services may locate it, e g. using its name and/or its elements as search criteria. For example, search criteria may be 
specified as an XML template document that may be compared (e.g. by the space service) with the advertisements in 
&e space. Published advertisements may represent "on-line" services ready for clients to use. The message address 
(URT) of tiie service may be stored as an element in the advertisement Advertisements that are removed from the 
space may transition back to the drafted state where they may be discarded or held. Removal may generate an event 
so mterested listeners may be made aware of the change. Message gates are typicaEy created from published 
advertisements. * 

In one embodiment, yet another possible state for advertisements is a persistent archived state. An archival 
procedure may turn a Uve published advertisement into a stream of bytes that may be persistently stored for later 
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reconstruction: Archived advertisements may be sent (e.g. in their raw XML form) from the space to an archival 
service. The UBI for an advertisement's archival service may be stored as an element m the advertisement XML 
may provide a format for storing and retrieving advertisements and representing the state of advertisement elements 
sufficient to reconstruct the advertisement object(s). Advertisements may be stored in other formats as well, 
depending on archival service implementation. The process of making a published advertisement persistent may 
prepare the advertisement for the persistent archived state. Persistent advertisements may be stored (e.g. by an 
archival service) for future use in a persistent storage location such as a file or a database. A space through the 
archival procedure may enable advertisements to be stored, however the space does not necessarily play a role in 
how persisted advertisement entries are actually stored. How persisted advertisements are stored may be determined 
by the advertisement's archival service. Typically, no events are generated on behalf of archived advertisements. 
Also, changes may not be allowed for advertisements in the persistent archived state. 

Advertisements may be archived and removed or just archived If an advertisement is arcWved wiflio 

removing it from the space, the space will store a shadow version of the advertisement Access to an archived 
service may cause the advertisement to "feult-m" from its persistent backing store on demand. This featmc msy 
5 aUow advertisements to be filled, from LDAP (Lightweight Directory Access Protocol) entries for example, on 

demand. • 

Figure 17 illustrates erne example of advertisement state transitions that an advertisement m^ undergo 
during its lifetime. First, an advertisement may be constructed, as indicated at 1. During construction, the 
advertisement is in the drafted state. Then, the advertisement may be mserted in a space, as indicted at 2. The 

0 advertisement may be inserted as a published parent The advertisement is in the pubUshed state after being inserted 
in a space. An event (e.g. AdvInsertEvent) may be generated when the advertisement is inserted in the space. 
Events are more fully discussed below. The advertisement may be archived and made persistent as indicated at 3, 
,vhich may transition the advertisement to the persistent archived state. An advertisement may also be published 
from the persistent archive state, as indicated at 4. An advertisement may be removed from a space and tnmsidon 

25 back to the drafted state, as indicated at 5. An event (e.g. AdvRemoveEvent) may be generated when the 
advertisement is removed. 

hi one embodiment the archived, persistent state is not used. In this embodhnent state changes 3 and 4 
also are not used. In this embodiment an advertisement is either in the drafted state or in the published state. 

Advertisements stored in a space may have fte followmg standardized elements and/or attributes: version 
30 (may be an element), creation date (may be an attribute), modification date (may be an attribute), hnplementation 
service ira (may be an element), and/orpersistence arcMval sennce UW (may be an 

A space itself is ^ically a service. A space service inay provide the abiUty to search for advertisements in 
the space, which may mclude searchmg the space by type of advertisements. A space service may also provide 
facilities to read advertisements, write (publish) advertisements, and take (remove) advertisements. A space may 
35 also provide the ability to subscribe for space event notification messages. Some spaces may provide extended 
facilities, such as faciUtles to navigate space relationsUp giaph by position; read, write or take advertisement 
elements; read, write or take advertisement attributes; and subscribe for advertisement event notification messages. 
Space fiiciUties are described m more detail below. A space's capabilities are embodied in a space advertiseinents 
message schema. From the message schema, space address, and authentication credential, a client message gate may 
40 be created to access the space and its facilities. 
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Spaces and all advertisements within a space may be addressed using URIs. In one embodiment, space and 
advertisement names may follow URL naming conventions. The use of URIs, e.g. URLs, for addressing spaces may 
allow spaces to be addressable throughout the Internet, in some embodiments. 

The space message recipient (a space service) may be specified using a URI which may have been received 
5 in a service advertisement for the space. The URI may include a protocol, host, port number, and name. The 
protocol may name the protocol that may be used to move messages between clients and the space (reliable or 
un-reliable sockets, for example). The host and port number may be protocol dependent IDs, The name may be the 
space name followed by advertisement, element and/or attribute name. In one embodiment, a pathname may be 
used to identify an advertisement in a space. Pathnames may be either absolute or relative. Absolute pathnames 
10 name the space as well as an advertisement Relative pathnames are relative a designated advertisement within an 
assumed space. In one embodunent, the syntax rules govermng the coiistruction of paifenames is that of liie URI 
(Uniform Resource Identifier). In that embodiment, advertisement and space names therefore mzy not contain any 
URI reserved characters or sequences of characters. Pathnames to elements and attributes may also be specified 
using a URI. In general, element and attribute names may be upended to the pathname of an advertisement, such 
15 as: 

http:A5ava.sun.com/spacename/adveitisement/element/attribute. • 
In one embodiment, the distributed computing environment may include a mechanism that allows a client 
to discover the URI of a space but restricts access to the service advertisement for the space. In one embodiment, 
rather than returning the full advertisement to the space, the URI of the space and the URI of an auflientication 
20 service for the space may be returned. In order for the client to access the documents or services advertised in the 
space, the client first may authenticate itself to the authentication service at the URI provided in the return message. 
The authentication service may then return an authentication credential that may allow the client partial or fiill 
access to the space. When the client receives the authentication credential, the client may attempt to cormect to the 
space to access the documents or service advertisements in the space, 
25 The distributed computing environment may provide a mechanism or mechanisms that may enable a client 

to connect to a space. Embodiments of a connection mechanism may provide for client-space addressing, client 
authorization, security, leasing, client capabilities determination, and client-space connection management A 
client-space coimection may be referred to as a session. In one embodiment, a session may be assigned a unique 
session identification number (session ID). The session ID may uniquely identify a client-space connection. In one 
30 embodiment, a session lease mechanism may be used to transparently garbage collect the session if the client does 
not renew the lease. 

The following is an example of using such a connection mechanism according to one embodiment A 
client may obtain an authentication credential. In one embodiment, the space may provide an authentication service 
in response to a client's request for access to the space. The client may obtain the authentication credential through 

35 the authentication service. When the client receives the authentication credential, the client may initiate a 
connection to the space by sendmg a connection request message. In one embodiment, the connection request 
message may include the URI address of the space service, the authentication credential for the client and 
information about the connection lease the client is requesting. After the space receives the connection request 
message, the space may validate the message. In one embodiment, an XML schema may be used to validate the 

40 message. The client may then be authenticated using the authentication credential In one embodiment, the 
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infonnation received in the connection request message may be used to determine the capabilities of the client to use 
the space. In one embodiment, each client of a space may be assigned its own set of capabUities for using the space. 
In one embodiment, an access control list (ACL) that may mclude capability infomiation about one or more clients 
of the space may be used in client capabilities determination. M one embodiment, the mfonnation received in ttie 
5 connection request message may be used to look up tiie client's capabilities in the ACL. 

After authenticating the client and detennming the clienrs capabilities, the connection lease to grant the 
cUent may be determined. After the lease is determmed, the structure for maintmning the client-space connection 
may be generated. A session ID for the connection may be generated hi one embodiment, each chent-space 
connection may be assigned a unique session ID. In one embodiment, an activation space may be created and 
10 assigned to, or alternatively a pre-existing activation space may be assigned to, the client-space session. In one 
embodiment, an activation space m^ be used to store results of services for the client vibax usmg the ^ce. M one 
embodiment, a client's capabilities msy be used to determine if an activation space is to be created for the client 
For example, a client may not have capabiHties to access an activation space to store and retrieve results. A message 
or messages may be sent to the client mforming the client that the connection has been established The message or 
15 messages may include the session ID and information about the lease. The client may then use the space including, 
but not limited to: advertisement lookup, advertisement registering, and advertisement retrieval. In one 
embodiment, he connection may remain open iratil the allocated lease expires or until tiie client sends a message 
requesting lease cancellation to tiie space. In one embodhnent, the cHent may be responsible for renewmg the lease 
before the lease expires. If the lease expires before the client renews tiie lease, the connection may be dropped, 
20 causing the client to lose the connection to the space. In one embodiment, to reconnect, the client may be required 
to repeat the connection procediure. 

In one embodiment, a client of a space may obtain a space's advertisement several different ways. Some of 
the ways a client may obtam a spacers advertisement are illustrated m Figure 18. For example, a space discovery 
protocol may be provided as part of the distributed computing envkonment Space discovery is a protocol a cUent 
25 or service may use to find a space. A Hstener agent 202 may be configured associated vdih one or more spaces to 
Usten for discovery requests. The discovery listener agent 202 may listen on various network interfaces, and may 
receive eitiier broadcast requests or unicast requests (at the URI of tiie agent) firom chents 200a looking for a 
space(s). The listener agent 202 then responds with the service advertisement<s) or URIs for the service 
advertisements of die requested space(s). hi one embodiment, the listener agent is, m general, separate from the 
30 space, because its fimctionaUty is orthogonal to the functionahty of a space service. However, the listener agent 
may be unplemented on the same device or a different device as a space service. 

In one embodhnent, the discovery protocol may be a service advertised m a default space. A client may 
instantiate the discovery protocol from the client's default space in order to discover additional spaces. The 
discovery protocol may be pre-registered with a cUent's default space. Alternatively, the discovery protocol may 
35 register itself with the defeult space by placmg an advertisement m tiiat space, e.g., when a client connects to a local 
network serviced by the discovery service. 

In one embodhnent, the space discovery protocol may be nmpped to underlying device d^^^ 

for other platforms, such as SLP, Jmi, UPnP, etc. Hius, a cHent may use the discovery protocol of the distributed 
computmg environment to find services in otiier envhonments., A bridge to tiiese other environments may be 
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provided, and advertisements provided to services in these other environments so that clients of the distributed 
computmg environment described herein may access them. Refer to the Bridging section. 

For each advertised discovery protocol, the distributed computing environment may create a subsequent 
results space to hold the results of the discovery protocol, hi one embodunent, space services m the distributed 
computing environment may use the Multicast Announcement Protocol (muMcast UDP) to announce themselves on 
a LAN. A listener agent may record this information. A device (either a cUent or service) may use the Multicast 
Request Protocol (multicast UDP) to initiate discovery of a space manager. In one embodiment, the space managers 
lespondAvith information indicating the URI of th^^ Alternatively, a hstener agent may respond . 

for multiple spaces. The discovery response may also mclude a short string that labels the each space (e.g. obtained 
fiom keywords of the space), and information that can be used to set up a TCP connection, for example, vvith each 
space manager to perform operations on the lespective space. Since the requestmg device may receive responses 
fiom more than one space manager (or multiple space listmgs fiom a listener agent), tMs mformation may help the 
client select whidi space it wishes to connect to. 

In addition to the multicast discovery described above, the discovery service may also perform discovery 
using unicast messaging (e.g. over TCP) that can be used to discover a space manager at a known address on the 
network (e.g. the hitemet, other WAN, LAN, etc). The unicast discovery message may mclude a request for a space 
service at a known URI to provide its service advertisement. The multicast and unicast discovery protocols are 
defined at die message level, and thus may be used regardless of whether the devices participating in the discovery 
support Java or any other particular language. 
) , The discovery protocol may facilitate the proliferation of cUents independently of the proliferation of 

server content that supports those cUents withm the distributed computing environment For example, a mobile 
client may have its initial defeult space buift into its local platform, hi addition to local services advertised in the 
default space, the mobile client may have services that search for additional spaces, such as a service to access the 
discovery protocol or a service to access space search engmes. 
5 hi one embodhnent, tiie distributed computing environment space discovery protocol may define a set of 

XML messages and thek responses that may aUow client to: 

* Broadcast protocol-defined space discovery messages on tiieir networic mterfaces. 
. Receive from Usteners XML messages describmg candidate spaces that those fisteners 
represent. 

10 • Select one of diose discovered spaces as default, wi&out tiiechentneeto^ 

address of the selected space. 
. Obtain information on the selected space, such as its address, so the cfient may la^^^ 
same space via means outside of the discovery protocol (usefiil if later tiie client w^ 
access a space which is no longer local, but i;^diich stiU is of mterest to 
35 M some embodiments, the multicast arid unicast discovery protocols may require 

these discovery protocols meet the needs of devices that are IP network capable, there are many devices that may 
not be directiy supported by these discovery protocols. To meet the needs of such devices m discovering spaces in 
the distributed computing enviromnent, a pre-discovery protocol may used to find an IP network capable agent The 
pre-discovery protocol may include the device sendmg a message on a non-IP network interface requesting a 
40 networkagent The network agent may set up a connection between itself and tiie device. Once the connection 
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between device and agent is set up, fte agent participates in the discovery protocol on IP networks on behalf of the 
device for which it serves as agent The network agent may also provide an interface for the device to the 
distributed computing environment in general. For example, gates may be coostructed in the agent on behalf of the 
device for running services advertised in discovered spaces. See the irirfging section. 

Another way that clients may locate spaces in the distributed computing eavironment is by advertisement of 
a space in another space. A space is a service, Ihereforeso, like any other Service, it can be advertised in another 
space. As shown in Figure 18, a client 200b may find an advertisement 206 in a first space 204a for a second space 
204b. Space 204b may m turn include advertisements to additional spaces. Because a service (implementing a 
space) may also act as a client, spaces may exchange advertisements or chain together to provide a federation of 
spaces, as illustrated in Figure 19. Any number of spaces may be included in the distributed cpmputmg 
environment Hie number and topology of spaces may be implementation dependent For example, spaces 
implemented on an IF network might each correspond to a different subnet 

Athirdwayaclientmaylocateaspaceisthroughnmningaseivice208.asshowninFigurel8. Aservice 

208 may be run which retams as its results the service advertisements of space services. Since service 
advertisements are XML documents and since Ihe distributed computing environment may include the Internet, 
service 208 may be a Web-based search tooL An example of such a s«vice is the space look-i^ service described 
in conjunction with Figure 4. In one embodiment, spaces wilhm fee distributed computing enviroranent may be 
implemented as Web pages. Each Web page grace may include a keyword feat may be searched upon to identify 
the Web page as a space in fee distributed computing environment The space may mclude ofeer searchable 
keywords as well to fiirther define fee space. A client may connect to a search service 208 and suppfy keywords to 
fee search service in the fonn of XML messages. The search service may receive fee keywords &om fee cUent and 
feed fee keywords to an Internet search engme, which may be a conventional or third-party search engme. The 
search service may return fee results ftom fee Internet search engine to fee client, eifeer directly as XML messages 
or by reference to a results space. Hie results may be fee UBIs of spaces matching fee search request 
Alternatively, fee search service may contact spaces identified by fee search, obtam fee service advertisement for 
each such space, and return fee space service advertisements to fee client, eifeer directly as XML messages or by 
reference to a results space. The cUent feen select a space from fee search results and construct a gate (by itself 
or through a proxy) to access fee selected space. Once fee selected space is accessed, fee client may look up service 
advertisements within that qiace, which m^ lead to additional spaces. 

As described above, a space may be an XML-based Website, and as such may be searched via Internet 
Web search mechanisms. A space may include Internet searchable keywords. Some devices, such as smaD clirat 
devices, may not support an Internet browser. However, such devices may still perform Internet searches for spaces 
withm fee distributed computing environment A device may have a program that accepts strings of keywords, 
which may be sent to a proxy program on a server (e.g. a search service). The proxy may send fee strings to a 
browser-based search fecility (e.g. an mtemet search fecility) to perform fee search, nie proxy may receive fee 
output of fee search and parse it into strings (e.g. XML strings) representing each URI for fee search results and 
send fee response strings back to fee cUent Thus, a clientmay locate spaces feiough fee hitemetwifeout having to 
support a program such as a Web browser. More capable devices may avoid fee use of a proxy and mMate an 
Internet-based search service directly. 
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A foiirth way a client may locate a space is by obtaining or receiving information about a newly created 
empty space or a spawned space when an existing space is spawned An existing space may include an interfece for 
spawning an empty space with the same functionality (e.g, same XML schema) as the space from which it is 
spawned. Spawning of spaces Is further described below. 
5 Once a client of a space finds the advertisement of a space service, tiaat client of the space may ran the 

space service, as it would any other service. Note that the client of the space service may be another service (e.g. a 
service seeking to advertise m the space). In one embodiment, as ilkstrated m Figure 20, to run a space service, the 
client of the space may first run an authentication service for the space to obtain an authentication credential, as 
indicated at 300. The authentication service may be specified in the service advertisement of the space service. The 
10 client of the space uses the authentication credential, the XML schema of the space (from space's s^ce 
advertisement), and the tJRI of the space (fiom space's service advertisement) to construct a gate for the space, as 
indicated at 302. Hie client of the space may then run the space service by using the gate to send messages to Ihe 
space service. A first such message is indicated at 304. 

For embodiments employmg authentication, when the space service receives the first message from tiie 
15 client, with the authentication credential embedded, the space service uses the same au&entication service (specified 
in the service advertisement of the space service) to authenticate the client, ftms establishing its identity, as mdicated 
at 306, Tbe space service may determine the client's c^abiUties and bind them to the authentication credentiaL, as 
indicated at 308, 

As indicated at 3 10, a client of a space may run various space fecilities by sendmg messages to the space 
20 service. In one embodiment^ when a client of a space sends a request to the space service, it passes its authentication 
credential in that request, so the space service can check the request against the cHenf s specific capabihties. 

Each space is typically a service and may have an XML schema defining tiie core functionahty of the space 
service. The XML schema may specify the client interfece to the space service. In one embodiment all space 
services may provide a base-level of space-related messages. Hie base-level space functionahty may be the basic 
25 space fimctionality that is capable of being used by most clients, including small devices such as PDAs. It may be 
deskable to provide for additional functionality, e.g. for more advanced cUents. Extensions to the base-level space 
may be accomplished by addmg more messages to the XML schema that advertises the space. For example, in one 
embodiment, the base-level messages do not impose any relationship graph upon the advertisements. Messages, for 
example, to traverse a hierarchy of advertisements may be a space extension. Such additional functionality may be 
30 provided through one or more extended XML space schemas or schema extensions for a space. The extended 
schemas may include the base schema so that clients of an extended space may still access the space as a base space. 

In one embodiment^ a base space service may provide a transient repository of XML documents (e.g. 
advertisements of services, results of running services). However, a base space service in one embodhnent may not 
provide for advanced fecilities to support persistence of space content, navigation or creation of space structure (e.g. 
35 hierarchy), and a transactional model. A mechanism for supporting persistence, hierarchy, and/or transactions is by 
extending the XML schema. Smce extended spaces still include the base XML schema, clients rosy still treat 
extended spaces as base spaces, when just the base space fimctionality is all that is need or all that can be siq)ported. 

In one embodiment, the base space may be transient The base .space may be acceptable for many 
purposes. Service providers may register then: services in various spaces. In one embodiment, services must 
40 continuously renew leases on the publishing of information in the spaces. By this nature, the services 
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advertisements may be transient in tiiat they may often be rebuilt and/or reconfinned. However, it may be desirable 
to provide for some persistence in a space. For example, a space that has results may provide some persistence for 
users that want to be sure that results are not lost for some time. In one embodiment, persistence may be provided 
for by specifying a space interface where the client may control which objects in the space are backed by a persistent 
store and manage the maintenance of that persistence store. The persistence interfece may be specified with 
extended XML schema for the space defining the interfeces for persistence. 

In one embodiment, a base space may provide an interface where an XML document may be added to a 
space and identified by a string. The base space may not provide any hierarchy for the various so named XML 
documents in the space. In embodiments where hierarchy support is desired, additional interfeces may be defined 
(extending the XML schema) where the user can specify a hierarchy. Other interfaces may be specified to navigate 
the hierarchy or navigate a relationship gi^h by position. However, other users still use the base ^ce 

interfeces to access those same documents, without any hierarchy. Interfaces for other space structure may be 

provided for as well in extended space scheraas. 

Extended XML space interfaces may also be provided for space transaction models. For example, an 

extended space XML schema may be provided specifying an interfece for ACID transactions. AGIO is an acronym 

used to describe four properties of an enterprise-level transaction. ACID stands for Atomichy, Consistency, 

Isolation, and DurabUity. Atomicity means that a transaction should be done or undone completely. In the event of 

a feilure, all operations and procedures should be undone, and all data should roUback to its previous state. 

Consistency means that a transaction should transform a system from one consistent state to another consistent state. 

Isolation means that each transaction should happen mdependently of other transactions occurring at the same tone. 

Durability means that completed transactions should remain permanent, e.g. even during system faihire. Other 

transaction models may also be specified in extended space schemas. 

Extended space schemas may be XML documents that specify the message interface (e.g. XML messages) 

for using extended space features, fimctionalify or facilities. A space may have a base schema and multiple 

extended schemas. This may facilitate provided different levels of service to different clients depending upon the 

client authentication. 

Besides extensions for space persistence, structure, and transactions, other space extensions may also be 
specified as deshed. For example, extensions may be provided to manipulate advertisements at tiie element or 
attribute level: read, write or take advertisement elements; read, write or take advertisement attributes; and subscribe 
for advertisement event notification messages. A space may provide virtuaUy any number of fecilities and arrange 
them in base and extended schemas as desired. In one embodiment, all base spaces must provide for advertisement 
reading, writing, taking, and lookup facilities, and space event subscriptions. 

Various space facilities may be provided. In some embodiments, a feciUty may be provided for the 
establishment of a session with the space. In one such embodiment, the rest of tiie space functionality is not 
available until tiiis is done. In other embodiments, the notion of a session is not provided for, or is optional and/or 

implementation dependent 

Another space fecihty may be to add or remove a service advertisement to or firom the space. A space 
facilify may also be provided for addmg or removmg an XML document (not an advertisement, but periiaps a result 
in a space). The space service may check for uniqueness of an item before aUowingtiie addition of the item. For 
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example, each item added to the space may be associated with a user-specified string tiiat identifies the item and that 
may be used to check for the uniqueness of the item. 

In one embodiment, a client may request a listing, tree or other representation of all services advertised in 
the space. The user then may scroll or maneuver through the advertisements and select the desh^d service. A space 

5 may also provide a look-up facility that allows a client to search for a service by providing keywords or string 
names. In one embodiment, a space facility may provide a mechanism to look up a space entry that has been added 
to tfie space. The look up facility may search by string to match for name, or wildcard, or even database query. The 
look up facility may return multiple entries from which the client may select one or perfomi" a fiirther narrowing 
search. In one embodiment, the look-up fecility may provide a mechanism to locate a service advertisement 

10 matchmg a particular XML schema. The cHent may kidicate a particular XML schema, or part of a particular XNIU 
to be seardied for within the space. Thus, a service m^ be searched for within a space acoHxiing to its interfece 
fimctionality. 

Another space facility that may be provided in the distributed computing environment is a mechanism that 
allows services and clients to find transient documents based upon a typing model such as XML. The mechanism 
15 may be a general-purpose, typed document lookqp mechanism. In one embodiment, the lookup mechanism may be 
based upon XML. The lookup mechanism may allow clients and services to find documents in general, includmg 
services through service advertisements. 

In one embodiment, a space lookup and response message pair may be used to allow clients and services to 
find XML documents stored within a network transient document store (space). The space may be a document 
20 space used to store a variety of documents, ha one embodiment, the documents are XML documents or non-XML 
documents encapsulated in XML. Spaces are further described elsewhere herem. Hie lookup messages may work 
on any kind of XML document stored in the space, mcluding service advertisements and device driver 
advertisements. In one embodiment, a client (which may be another service) may use a discovery mechanism as 
described elsewhere to find one or more document spaces. Then, the client may use space lookup messages to 
25 locate documents stored in the space. 

The distributed computing envkonment may include a mechanism that allows services and cfients to 
subscribe to and receive events about the publication of XML documents. Events may include die publication of 
and removal of XML documents to and from a transient XML document repository such as a space. In one 
embodiment, an event may be an XML document that refers to another XML document 
30 In one embodiment, a space event subscription and response message pair may be used to allow clients and 

services to subscribe for events regarding docmnents that are added to or removed from a space. In one 
embodiment, an event subscription may be leased using the leasing mechanisms described elsewhere herein. In one 
embodiment, a subscription may be cancelled when the lease is cancelled or expires. In one embodiment, renewing 
the lease to the subscription may renew a subscription. 
35 In one embodiment, an event subscription message may include an XML schema that may be used as a 

document matchmg mechanism. Documents that match the schema may be covered by the subscription. In one 
embodiment, any document added to a space and that matches the XML schema may generate a space event 
message, . 

A space fecility may also be provided to which a client may register (or unregister) to obtain notification 
40 when something is added to or removed from Hxq space. A space m^ contain transient content, reflecting services 
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that at added and removed from the space. A mechanism may be provided to notify a client when a service becomes 
available or becomes unavailable, for example. A client may register with an event service to obtain such 
notification, hi one embodiment, a client may register to be notified when a service havmg a name matchmg a 
specified string or a schema matching a specified schema (or schema portion) is added or deleted from the space. 
5 Thus, a query to register with the space event notification facility may be the same as or similar to that of the service 
look up facility described above. 

When a client of a space subscribes to be notified when an XML document(s) (e.g. service advertisement) 
is added or removed from the space, the client may obtain a lease on this subscription to notifications. The lease 
may allow the space service to know whether to contmue sending notifications to a particular client For exaniple, a 
10 lease to tiie notification facility may expire after an amount of time if not renewed. Note that a lease not be 
required while a client has established an active session with a space. Once, a client has discontinued an active 
session with a space, the client may continue to receive event notifications according to its event subscriptions as 
long as its correspondmg leases remain active. Refer to the Leases sectitm below. 

A client may subscribe to different types of events. Examples are a service advertisement being added or 
15 removed from a space, as described above. A client may also be notified when results from a service mitiated by the 
client (or by someone else) are put m a space. For example, the client and the service may mutually select a name 
for referring to the results of the service. The client may register wit£ the space service to which the results are to be 
posted or advertised to receive an event when a result referenced by the selected name is added to the space. 

A space may generate different types of events to which a cUent may subscribe. As the composition of a 
20 space changes, events may be produced to those clients and services that have subscribed for such events. In one 
embodknent, there may be two major space event categories, those tiiat pertain to the space (insertion and removal 
of advertisements), and those used that indicate changes to an advertisement (addmg, removmg, changing an 
element or attribute). Which events are supported may be indicated in the XML message schema for the space. 

The following events are examples of events that may be produced by a space service to indicate a space or 
25 advertisement event * 

Table 1 



Space Events 



EveiatName 


Type 


Meaning 


Advertisement 
Insertion Event 


AdvInsertEvent 


New advertisement has been inserted 
into a space 


Advertisement 
Removal Event 


AdvRemoveEvent 


Existing advertisement has been 
removed from a space 


Advertisement 
Element Insertion Event 


AdvElementlnsertEvent 


A new element has been added to an 
advertisement 


Advertisement 
Element Removal Event 


AdvElementRemoveEvent 


Existing element has been removed 
from an advertisement 


Advertisement 
Element Change Event 


AdvElementChangeEvent 


Existing element has been changed in 
an advertisement 
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Advertisement Element 
AunDuie inscraon liyeni 


AdvElementAttributelnsert 
jtiveni 


A new attribute has been added to an 


Advertisement Element 
Attribute Removal Event 


AdvElementAttributeRemove 
Event 


Existing attribute has been removed 
from an element 


Advertisement Element 
Attribute Change Event 


AdvElementAttributeChange 
Event 


Existing iattribute has been changed in 
an element 



Events may be typed. In some embodiments, the event fecilities supported by spaces may allow for event . 
listeners to take advantage of, e.g., Java class (or XML types) hierarchies. For example, by listening for 
AdvElementEvent, the listener will receive events of type AdvElementEvent and all of its suh-classes (XML types). 
Thus, for this example all events pertedning to element changes (though not advertisement insertion and removal) are 
received. 

By way of further example, subscribing to or listening for a top-level event class or type, e.g. SpaceEvcnt, 
will result in the reception of all space events. Event class types may be distinguished via, for example, the Java 
i/w/a«ceo/operator or the XML typing system. 

An event may include a URI to the affected advertisement or element For example, AdvertisemeatEvent 
and all its sub-classes may contain a reference (e.g. URI or URL) to the affected advertisement AdvElementEvent 
and its subclasses may be examined for the name of the affected element The previous element value (URI or 
URL), may be available, for example, from AdvElementRemoveEvent and AdvElementValueChangeEvent 

A space event type hierarchy for one embodiment is illustrated in Figure 21 . Types may be deiBned in XML 
and usable in Java or any other suitable object-oriented language such as C++. 

A space may provide a facility for a client to instantiate a service advertised in the space. Service 
instantiation is the initialization done that allovre a client to be able to run a service. On embodiment of service 
instantiation is illustrated in Figure 22. To instantiate a service, a client may first select one of the service 
advertisements published in the space, as mdicated at 320. The client may use the various fecilities, such as the look 
up facility, provided by the'space to look up the various advertisements in the space. Then the client may request the 
space to instantiate the service, as indicated at 322, 

In one embodiment, service instantiation may include the following actions. After the client requests the 
space service to instantiate the selected service, as indicated at 322, the space service may then verify the cUent is 
aUowed to mstantiate the requested service, as indicated at 324. The space service may perforai this verification by 
examining an authentication credential included in the client's message. The authentication credential is the 
credential the client received when it established a session with the space service. The space service may verify if 
the client is allowed to instantiate the requested service according to the client's autiientication credential and 
capabilities indicated for that client See the Authentication and Security section herein. 

Assuming the client is authorized, the space service may also obtain a lease on the service advertisement 
for tiie client with the lease request time specified by the client, as indicated at 326. Leases are lurther discussed 
below. The space service may then send a message to the client which mcludes the allocated lease and the service 
• advertisement of the service, as mdicated at 328. In one embodiment, the client may run an authentication service 
specified in the service advertisement and obtain an authentication credential, as indicated at 330, See the 
Authentication and Security section herein for more mformation on an authentication service, Kext, as indicated at 
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332, the client may construct a gate for the service (for example, using the aathentication credential and the XML 
schema and service URI ftom the advertisement). Refer to the Gates section herem. The above described 
communication between the client and space service is performed using the XML messaging of the distributed 
computing environment. The client may then run the service usmg the constructed gate and XML messaging. The 
5 service may similarly construct a service gate for XML message communication vrith the client 

To summarize, an example use of a space is discussed as follows. A cUent may access (e.g., connect to) a 
space service. (A service may act as a client for the purpose of accessing or otherwise using a space.) Tl»e space 
service may stor« one or more service advertisements and/or other content in a space, and each of the service 
advertisements may include information which is usable to access and execute a corresponding service. The space 
10 service may include a schema which specifies one or more messages usable to invoke fimctions of t^^ 

For example, the schema may specify methods for raiding advertisements fix)m the space and publishing 
advertisements in the space. The schema and service advertisements may be expressed in an object representation 
language such as extensible Markup Language (XML). In accessing the space service, the client may send 
information such as an XML message (as specified m the schema) to the space service at an Mtemet address. In 
15 accessing the space service, the client may search the one or more service advertisements stored in the space. The 
cUent may select one of the service advertisements from the space, hi one embodiment, the client may send an 
instantiation request to the space after selecting the desired service advertis Aleasemaybe 
obtained for the desired service, and the lease and the selected service advertisement may be sent by the space 
service to the cUent The client may then construct a gate for access to the desired service. The desired service may 
20 be executed on behalf of the client. 

Another facility provided by a space service may be the spawning or creation of an empty space. This 
space facility may allow a client (which may be a service to another client) to dynamically create a new space. In 
one embodiment, this space fecility may mclude an interfiice for spawning an empty space with the same 
fimctionality (same XML schema or extended schema) as the space from which it is spawned. This fecility may be 
25 usefid for generating (e.g. dynamically) spaces for results. For example, a chent may spawn a space a request a 
service to place results or advertise results m the spawned space. The cUent may pass the spawned space URI 
and/or authentication credential to the service. Or a service may spawn a space for results and pass the spawned 
space URI and/or authentication credential to the client hi some embodiments, once a space is spawned, it may be 
discovered just like other spaces using one or more of the space discovery mechanisms descnTiedhere^ 

30 By using a mechanism in which a space may be created via an mterfece in another space (e.g. a space 

spawning facility), new spac«; may be created efficiently. For example, in one embodiment, storage for the 
spawned space may be aUocated using the same facihty used by the origmal space for stortige. Also, a spawned 
space may share a common service fecility with its original (or parent) space. For example, a new URI may be 
assigned to the new space, in one embodhncnt, the new URI may be a redirection to a conmion space feciTityshart^ 

35 whh the original space. Thus, a newly spawned space may use the same or some of the same service code as that of 
the original space. 

■ Space faciliUes may also include security administration, for example, to update the various security 
poUdes of the space, and other admmistratiVe facilities. For example, the number and age of advertisements may be 
conholled and monitored by a root space service. Old advertisements may he collected and disposed. See. e.g., the 
40 LeasessectionhereinforwhenanadvertisementmaybeconsideredoW. Hie service hnplementing the space may 
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be under the control of an administrator. The administrator may set policy in a service dependent manner. Space 
facilities may also include a facility to delete an empty space. 

Certain spaces may include facilities or sendees to further supportthe proliferation of ^ 

as mobile cUenls. For example, services in spaces that a mobile cUent may discover, e.g. via the discovery protocol, 

5 may provide support for mobile clients, such as: 

• Assigning and admmistering temporary netwoik addresses for the client 

Proxying message passing for the client 

Providing search facilities for additional spaces. For example, a service ma/ allow a 

client to specify keywords through a simple mterface. The service then uses the keywords in 
10 conjunction with Web search engmes to search for spaces on the Web. as fiirtherdescn^ 

herein. In other embodiments, a seaidi service may constrain clients to seardnng onty a ft^ 

supported spaces within the distributed computing environment. 
A5 mentioned earUer (see Figure 9 and accompanying text), spaces may provide a convenient mechamOT 

for storing results from a service run by a client Using a space for results may allow a small client to receive in 
15 pieces the results of imming a service. Some services may generate a large amomit of results. By usmg a space to 
store the results from a service, cUents tiiat do not have the resources to recdve the fidl resists at once m^ still use 
Iheservice. Moreover, by using a space to store results, a service running on a fast busy server may be freed from 
interacting directly with a slow client when returning large results. Thus, the service may be fit»d sooner for use by 
other clients. 

20 A space may provide a convenient mechanism for accessing a result by different clients and/or at different 

times. For example, a client may not be able to use the entire result, but a user may want to access the rest of the 
• result later using another cUent that can access it For example, the result could be stock quote infiMmation, showing 
the current price of a stock (accessible by a PDA), and showing a chart of stock prices (accessible by a laptop later). 
Also, using a space in the distributed computing environment for results may aUow a client to feed the result of one 

25 service into another service, without the necessity of downloading the result first For example, in the case of the 
stock quote information above, the PDA could feed the chart into another service, which prints the chart, without 

PDA having to download the chart itsell Thus, a results space may provide a mechanism for a cUent to pass to 
another client or service wifliout the client having to handle or receive the results. 

hi different embodhnents. the decision to use a space for results may be mandated by the ser^ce, mandated 

30 by the cUent, and/or requested by the client A service may suggest the use of a space for its results. e.g., in its 
advertisement hi one embodiment, either the cUent or 4e service may spawn a new space for results or use an 
existing space for results. See the description herein regarding spawning spaces. 

hi one embodhnent, the nse of a q>ace for results does not necessarify mean fliat the service must put aU 
results in that space. There may be alternatives for any result a service generates. For example, part or all of the 

35 result may be sent in-line m a message to the cUent Alternatively, the result may be put in the space, and then a 
notification message may be seat to cUent. referencing the result (e.g. including a URI to the result or to an 
advertisement for the result). Another option may be to put the result m the space, with notification via an event 
from the space. For example, the client and the service may agree to call the result some particular name, and then 
the cUent may register with the space (using a space facility such as described dWve) to receive an event when a 

40 result so named is added to the space. See the description above on event notification. 
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Thus, several different mechanisms may be employed wittiin the distributed computing environment for a 
service to return results to a cUent The actual results may be returned to the client by value in an XML message, or 
results may be returned to the client by reference with the actual results (or advertisement for the actual results) put 
in a space and the client receiving a message referencing the results in the space. Moreover, results, or results 
advertisements, may be placed in a space and the client notified by event. 

Another mechanism for handlmg results may be for the client to specify another service for the results to be 
fed to. For example, when a cUent runs a service that will produce results, the client may instruct that service (e.g. 
through XML messaging) to send the results to another service for flirther processing. This may mvolve the client 
indicating the UW of an advertisement for the other service so that the result-producing service may generate a gate 
to the other service in order to run the other service and pass it the results. In this example, the result-producing 
service may be a client of Ae other service. In some embodiments, Ae cUent m^ send the schema or a pre- 
constructed gate to the result-producing service to access the serWce for finther process Ancxan^ikof aservice 
for fiirther processing is a display service that may display the results for the origmal client This display service 
may be on or associated wiftk the same device as the client 

Result spaces and method gates may aUowthe distributed computmg environment to provide a simple 
remote method invocation that is practical for thin clients with minimal memory footprints and minimal bandwidth, 
because it need not have fte adverse side effects of huge program objects (along with needed classes) being reh^ 

(necessarily) across the network to the client as in conventional remote method mvocation techniques. Instead, 
results may be returned to a result space, and only if desired (and if they can reside on the client) are the actual 

objects downloaded to the client 

The mechanism by which the distributed computing environment may provide for remote method 
invocation is as follows (refer also to the description of method gates in the Gates section herein). An object may be 
advertised (e.g. as a service or as part of a service) in a space. Tlie advertisement includes a reference that contams 
the tW (e.g. URL) of the object, along with other access parameters, such as security credentials and XML schema. 
A client may have or may constmct a client method gate for flie object, which for every method of the object (or 
service) itself may have a wrapper method tiiat takes the method parameters and creates a request XML message to 
invoke a method of the object The XML message is sentto a service gate that mvokes the actual method on the 
service object When that method returns a result object, the service gate may post the result object in a results 
space, and may return a message to the client vrith a referaice to the result object 

TTius, for a client to invoke a remote method, the client first sends a message to instantiate an object (e.g. 
service), such as described above. In one embodiment, instantiation of an object may include the creation or 
spawning of a results space, to another embodiment, results space creation may be independent from the object 
instantiation. Instantiation may retmn the object URI to the client, and the cUent and service gates may be 
dynamically created when a cUent requests instantiation, hi some embodiments, a results space may already exist 
and be advertised by the object (service). Some part or aU of flie gates may also have been pre-consbucfed or 
reused. 

Once a client has initiated an object a local caU of 4e appropriate client method gate wiU affect a rmote 
can to the actaal remote object, as described above. The remote method mvocation approach of the distributed 
computing enviromnent may be recursive, with object references returned to the cUent, mstead of the objects itself 
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when the client gate is called. Note that such returned objects may akeady be instantiated In some embodiments, 
the client may make a decision to download an entire object itsel£ rather than just remotely invoke it 

A method or service invoked as described above may generate a child gate that is associated with the 
results document; The method may return a child gate (or the schema, XJRI and credentials for the client to construct 
a child gate) for the references instead of the references themselves. The client may then access tfie references 
flirough the child gate. The child gate may also be a mediod gate. 

As described above, this remote method invocation provided by the distributed computing enviroimaent 
allows the real result object(s) to be stored in a service results space (vMch also may be created dynamically, by a 
servlet for example). The results space may be temporary. The results space may act as a query results cache. The 
results cache may be patrolled by server software (garbage collector) that cleans-up old result areas. Distributed 
garbage collection may be employed, as result spaces mary fill up until lhey are destroyed by a client indicating it no 
longer needs the space, or by an administrator on a server setting ^propriate limits. 

Turning now to Figure 23, an illustration of a default space 350 is provided. The distributed computing 
environment may provide at least one default space so clients can find an initial set of advertisements. A device may 
have a default space that exists locally, with a built-m pre-constructed gate. The services advertised in that default 
space may exist locally on that device, and they may provide system sotlware that enables or facilitates the device^s 
participation in the distributed computing environment 

The defeult space 350 may include one or more mechanisms 352 to locate external spaces, as shown in 
Figure 23. One service m the default space may run the space discovery protocol described above to find external 
spaces. Also, extemal spaces may be advertised in the default space. Additional^, a service (e.g. a search engine or 
a proxy service to a search engine) may be advertised m the default space Aat determmes or finds extemal spaces. 
Each space may be analogous to a file system mount point Thus, the distributed computing environment may 
provide searchable, dynamic mount points to services. A default space may be a client's initial mount pomt to the 
distributed computing environment, 

A default space or access to a defeult space may be built in to a device. Through the defeult space and 
local services that may exist on the device, a client execution environment for the disttibuted computing 
environment may be provided, A device's local services and defeult space service may have built-m pre-constructed 
gates. One of the built-in services listed in the deJ^ult space may be a service to run the discovery protocol so that 
the client may locate additional (e.g. external) spaces. A default space may include a built-m service that provides 
an execution environment for clients that allows the cUent user to browse spaces, select, and then instantiate 
services. Such a service may provide a simple user mterface that allows a client to entire strings (e.g. keyword for 
space searches), view or browse result references (e.g. space listings, or service listings within a space), select items 
(e.g. to chose and instantiate a service), etc. 

Devices that prfanariiy provide a sendee may also include a defeult space and may mclude a built-in service 
in the default space that allows a service to manage advertising itself m various spaces. For exan^le, a device, such 
as a printer, may have a built-m default service that finds ^perhaps through the discovery protocol) a space on a local 
area network and adds an advertisement for the printer service to that space. This service may also maintain the 
printer service advertisement within the LAN space, for example, by renewing its lease or updating the printer's 
XML schema, etc. 



56 



PCTAJSOl/15134 

WO 01/86394 

For some devices that provide a service, the overhead of finding a space to advertise its service and 
maintain that advertisement is undesirable. In one embodiment, rather than searching for and maintaining a space or 
spaces to publish service advertisements, services on some devices may transmit their advertisements in response to 
connection requests. For example, a printer device with a printer service that is available on a proximity basis may 
5 not maintain an advertisement in a space (on the device or external to the device). Instead, when another device 
estabUshes a connection with the printer device (for example, a user with a laptop rumiing a client desires to print a 
docmnent), the printer service may transmit the service advertisement to provide the XML service schema for 
connecting to and running the service that provides printing functionality on the printer device. Also, some devices 
may only maintain advertisements for their services m a certain vicmity or local network. Such a device may not 
10 desire to support or may not have access to transports for broader accessibility. 

One example of a service device m which it may be desirable for the device to avoid or limit m^ 

service advertisements in a space is a device whose functionality is available on a proximily basis. Pioxhnity-based 
services may provide advertisements of their fimctionality upon request lliese advertisements may not be broadly 
accessible. For example, proximity-based services may be provided in a wireless communications system. The term 
15 "wireless" may refer to a communications, monitoring, or control system in which electromagnetic or acoustic 
waves cany a signal through atmospheric space rather than along a wire. In most wireless systems, radio frequency 
(RF) or mfiared (IR) waves are used. Typically, in proximity-based wireless systems, a device comprising a 
transceiver must be within range (proximity) of another device to establish and maintain a communications chamiel 
A device may be a hub to connect other devices to a wireless Local Area Network (LAN)- 
20 As mentioned, embodiments of the distributed computing environment may provide a mechanism using a 

lookup space that allows clients to rendezvous with services, m a proximity computing enviromnent, one 
embodiment of the distributed computing enviromnent may provide a service discovery mechanism that clients may 
use to discover services without usmg lookup spaces as rendezvous points. An example of a proximily compntmg 
enviromnent is an IrDA pomt-to-point commmucations environment In a proximity computing enviromnent, the 
25 proximity mechanism may find the "physical" location of the service for the client For example, in an IrDA 
enviromnent, the cUent device may be physicaUy pointed at the device includmg the service(s) that the cUent desires 
to use. 

The proximity service discovery mechanism may enable the cUent to directly look for service 
advertisements rather than sendmg a lookup request to a lookup space to look for service a^^^^ Sincethe 
30 client device may have established a proximity comiection to the service device, the cUent may directly request the 
desired service. For example, a PDA cUent device may estabUsh a proxhnity connection to a printer device; the 
cUentmay "know" to request a printer service connection on the printer device. 
' In one embodiment, the cliem may send a proximity service discovery message to the service d^^^^^ 

message may include mformation that may specify a desired service on the service device to which the cUent device 
35 has a proximily comrection. In one embodiment, a service on tlie service device may respond to the pn>xhnity 
service discovery message, and may sendto the client the service advertisement that the cUentmay use to comiect to 
the desired service. The proximity service discovery message may also include information that may be used to 
authenticate the client and to establish the cUenfs capabilities on the service. Using the received service 
advertisement, the client may establish a gate to establish commmiication with the desired service. 
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Nevertheless, it may still be desirable to pubUsh advertisements for services that do not desire to or camiot 
mamtain fteir advertisements in a space &at is broadly accessible. In one embodiment of a distributed computing 
environment, a device that establishes a comiection with a device that does not publish its service advertisement{s), 
such as a proximity-based device, may pubUsh service advertisements received from the non-publishing device. For 
5 example, a device that establishes a comiection with a proximity-based device and that has an alternate transport 
comiection(s) may publish (or republish) service advertisements received from the proximity-based device in the 
alternate transport enviromnent, thus aUowing the proximity-based device service(s) to be used by other devices 
(through the (re)published service advertisements) wMch are outside the normal proximo 

The publishing device may locate a locally published service advertisement for the proximity-b^^^ 

10 through a discovery and/or lookup service, or alternatively the service advertisement may not be published by the 
local service device, but instead may be sent to the publishing device by the local device upon the establishment of a 
comiection, as described above. In one embodiment, the republished service adverti^^ 
as long as the device maintaining the advertisement is comiected to or able to connect to the local device. For 
example, if the pubUshing device is discomiected from the local device (for example, moves out of proximity range 
15 of the device), the service advertisement may be made stale or removed. A lease mechanism may be provided to 
allow the space containmg the advertisement to send lease renewal messages to the publishing device. The 
publishing device may verify its connection to the local device, flius allowing the space to detect when the local 
device is no longer available. Rules for how the service advertisements are republished may be provided by the 
local device or by an administrative policy for the local vicuiity (e.g. proximity area) or local networiL 
20 Figure 24 illustrates an example of a device bridging pioximity-based devices onto another transport 

mechanism to allow the services provided by the proximity-based devices to be accessed by devices outside the 
proximity range of the devices, accordmg to one embodiment A publishing device 1404 may be comiected to a 
network 1412, such as an Ethernet LAN or the Internet, etc. and may establish and maintain proximity connections 
1414 with proximity devices 1400 and 1404. Proximity connections may be wireless comieclions or wned LAN 
25 comiections. for example. Proximity devices 1400 and 1402 may each send a service advertisement to the 
publishing device 1404 upon comiection, or. alternatively, the publishmg device may locate the service 
advertisements using a discovery and/or lookup service for the proximity comiections. Tlie publishing device 1404 
may then make the services provided by the proximity devices available to other devices 1408 and 1410 on the 
network 1412 by lepubUshing the service advertisements 1416 and 1418 in space 1406. Space 1406 msqr be stored 
30 onthepubl.shingdeviceoronotherdevicescomiectedtoflieLAN(mcludingdevicesl408andl410). 

Oflier devices on the LAN includmg devices 1408 and 1410 may then discover space 1406 and look up the 

republished service advertisements 1416 and 1418 for the proximity-based devices, establish gates to communicate 
tolhose services (device 1404 may act as a proxy or bridge) on the proximity-based devices 1400 and 1402using 
the XML message passing methods described previously, and send requests and receive results to the proximity 
35 devices. Publishing device 1404 may act as a bridge between the networic 1412 and the proximity comiections 1414 

to the proximity-based devices. 

Leases * 

Leases may be used in the distributed computing environment to deal with partial Mure, resource 
40 synchronization (scheduling), and to provide an orderly resource clean-«p process. Leases may help the overall 
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distributed system manage independent clients and services that may come and go. The various resomx:es that 
clients obtain from services (including space services) may be leased from those services. In general, not every - 
resource can or needs to be leased. In one embodiment, it is up to the implementation of each particular service to 
determine which of its resomces need to be leased. In particular, resovurces used by a large amount of clients 
5 simultaneously may not need leasing or instead may require custom leasing protocols. This class of leasing may be 
left to the service provider. Custom protocols^ such as those to implement transactions for example, may be built 
upon the base leasing scheme. In one embodiment, the base leasing model is a relative time-based model. 

Services may issue leases to clients and provide operations on those leases. In one embodiment, all such 
lease fiinctionality of a service is part of that service's XML schema. Thus, a client may use its gate (corresponding 
10 to the service and constructed for the service's XML schema) to perform lease operations. In one embodunent, aD 
services that issue leases provide the following lease operations (only allowed by tibe owner of the lease): (i) 
renewing a lease (parameters specified: lease' (e.g. lease ID, lease credential), new lease time requestedX and (li) 
canceling a lease (parameter specified: lease (e.g. lease ID, lease credential)). In one embodiment, all leases are 
granted for a particular amount of relative time (duration of lease) that may be negotiated. The requestor may 
15 specify a certain amount of time (e.g. in seconds), and the grantor may grant the lease for any amount up to that 
time. In one embodiment, a -1 value may be used to specify an indefinite lease. 

In one embodiment, a service advertisement may include one or more leasing addresses. In one 
embodunent, the leasing addresses may be URIs. Standard leasing messages to renew and cancel service resource 
leases may be sent to a leasing URI, An example lease URI: 
20 <Ieaser>servicel://resourcel</leaser> 

An advertisement may also include various leasing messages as described above. Leasing messages may 
include messages to renew and cancel leases for resources of the service. In one embodiment, the messages may be 
comprised in an XML schema in the advertisement 

The leasing mechanism may provide a mechanism to detect service and chent failure. Leases may also 
25 provide a mechanism to provide shared and exclusive resource access. In one embodiment, all service resources 
either have no lease (resource is not leased and therefore available), a shared lease (resource accessed by multiple 
clients), or an exclusive lease (resource is accessed by exactfy oiie client at a time). In one embodiment, all 
resources begm in the no lease state, A no lease state signifies there is no current access to the undertying resource, 
and indicates that there is an interest in the resource remaming in existence and thus available for leasing. The 
30 leasing level may be increased fi^om none to shared, none to exclusive, or shared to exclusive. Lease isolation levels 
may also be decreased from exclusive to shared, exclusive to none, and shared to none. In one embodiment, clients 
may voluntarily increase or decrease the lease isolation level, or may be requested by the service to do so. A 
response message from the service may indicate if the isolation level change was accepted. 

Request-response message pairs may be employed to claim, release, and renew a lease. Each message may 
35 be tagged using a reserved XML tag to indicate that the message is a leasing message. The distributed computing 
environment doesn't necessarily define the complete composition of the message. In such an embodiment, service 
developers may append cnstom message content, as long as, the niessage is tagged as a leasing messj^e. 

In one embodiment, clients that use leased resources may be ejected to: (i) claim the resource as shared or 
exclusive, (ii) release the resource claim (if requested or if finished with resource), and (iii) respond to renewal 
40 messages (with another claim at same or different isolation level). Renewal messages may be sent (e.g. m regular 
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intervals) by services to detect client failure cases. The interval (at which the renewal message is sent) may be 
service specijac. If a response to the renewal message isnt issued after a specific amount of time (e.g. based on a 
time noted in the service advertisement), a resource reclamation process may begin within the service, revoking the 
lease completely. In such an embodiment, renewal messages sent to clients should be handled in a timely fashion. 
Figure 25 illustrates the use of renewal messages both between a client and an instantiated service and between a 
service provider and a space service. Note that both cases may be considered as the use of renewal messages 
between a client and a service, since a service provider may be a client to a space's advertisement service. 

Renewal messages may arrive in an "out of band" fashion that may be inconvenient for the client to handle. 
That is, the client cannot predict when a renewal message will be sent from the service. Out of band message 
handling may complicate the client's logic and increase its complexity. To solve this problem, an automatic lease 
renewal mechanism may be implemented to relieve the client of the responsibility of handling liie out of band 
messages, and liius reduce client complexity. In the automatic lease renewal mechanism, each gate (message, 
method, and/or event gate) may receive renewal messages and automatically respond to them without help from the 
client Hie default response to a renewal request is to claim the lease at its current level. Each message gate may 
contain a single, set-aside renewal response message that is automatically sent to the advertisement space service 
when the gate receives the renewal message. This "out of band" message is haiidled on behalf of the client, yielding 
a cleaner client programming model. In one embodiment, the gate may allow clients to regjsto- lease event handlers 
to specily different isolation levels in the response message. 

The leasing mechanism may also provide a mechanism to detect stale advertisements. When a service 
pubhshes its advertisement in a space, that service obtains a lease on this publishing of its advertisement Each 
advertisement may contain a time by which the service promises to renew the advertisement In one embodiment, 
all time-out values are specified in seconds. If the service contmues to renew its lease, the space is provided some 
assurance that the service advertised is still being offered The renewal time may be counted down towards zero by 
the space service. If the service does not renew its lease, the service may have failed, or it may no longer v*ash to, or 
be able to provide the service. When the lease is not renev^ed, the space service marks the service advertisement 
stale, so it does not make it available to clients. Services renew advertisements by sending a renewal message to the 
space. The space service receives these messages and resets the advertisement renewal time back to its initial value. 

In one embodiment, stale advertisements are not automatically deleted. Depending upon the policies of tihe 
space, it may choose to delete stale service advertisements that have esqpired for a reasonably long period of time. 
The deletion policy may be set by the space service. The space service may search for stale advertisements and 
either delete them or bring them to the attention of an administrator, for example. 

A space service may use leases to manage the resources its fecilities provide to clients (including other 
services) of die space. For example, when a client desires to use a service, the space service may request a lease for 
the client as part of service iustantiation. Service instantiation may be performed to allow a client to run a service. 
To instantiate a service, a client may first select one of the service advertisements published in a space. The client 
may use die various feciLities provided by the space to look up advertisements m the space. Then the client may 
request tiie space to instantiate the service. The lease acquired during service instantiation is on use of the service 
advertisement (not the same as the lease on publishmg of the service advertisement). It should be noted that the 
space service m^ allow multiple clients to have a lease on use of a service advertisement if the advertisement has an 
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indication it is shared Otherwise, the space service only allows oae client at a time to have a lease on the service 
advertisement (exclusive). 

Another example of how a space service may uses leases to manage the resources its facilities provide to 
clients is when a client of the space registers to be notified when XML documents (e.g. service advertisements) are 
5 added or removed from a space. The registermg cUent of the space may obtain a lease on this subscription to 
notifications. This lease enables the space service to know whether to continue sending notifications. Such a lease 
may not be necessary wlien a cUent has established an active session with the space. Also, note that when a client of 
a space (could be a service) establishes a session with the space, the client may obtain a lease on the session. This 
allows the space to manage any resources associated vnth the session, 
10 In another embodiment, the distn^nted computing environmem may employ a 1^ 

not time-based. The lease may be generated M^en an object is claimed for use. Instead of a tfane-based mechanism, 
the claim method may accept a callback that notifies tiie current leaseholder that some otiier party i;wshes access liie 
same object (e.g. service). Thus, as an alternative embodiment to time-based leases, instead clients may m^e 
clauns on space objects (e.g. services). When another client desires a lease that is incompatible with the current 
15 leaseholder's lease, tiie service may send a "callback message** to die client. Upon receiving the cdlback message, 
tiie client (i e client gate) may invoke a callback mefliod to decide on a response to die callback message (keep &c 
lease, cancel die lease, change tiie access level to shared, etc.). Once a response has been determined, liie client gate 
sends a response message to the service. This distributed mechanism for managing leases may be implemented 
using tiie XML message-passing layer. 
20 For a non-time-based lease embodiment, die distributed computing environment may provide lease support 

for several levels (or kinds) of access tiiat aUow a distributed algoritimi to determine lease con^atibility. Those 
levels may include: (i) keep tiie object in tiie space OceepInSpace), (uj read tiie object in tiie space (readShared), and 
(iii) read exclusively the object m tiie space (readExclusive). 

25 Autiientication and Securitv 

The distributed computing envnonment provides for spontaneous and heterogeneous distributed systems 
based upon an asynchronous message passing model, where data and/or objects may be represented in a 
representation language such as XML. In tiie distributed computing envnonment, clients may connect to services 
tijroughout tiie Internet, for example. The distribtrted computing environment may enable large numbers of network 

30 devices to work togetiier in a reliable, dynamic, and secure feshion. The distributed computing environment may 
define a protocol tiiat substantially enables interoperability between compliant software components (clients and 
services). 

In tiie context of tiie distributed computing environment, a device may be a networidng transport 
addressable unit Clients and services may be implemented as Universal Resource Identifier (UTO) addressable 
35 instances ofsoflware orfinnwarediatrun on devices. 

Internet space is inhabited by many points of content A URI is a metiiod used to identify any of tiiose 
pomts of content, whetiier it be a page of text, a video or sound clip, an image, software, firmware or otiier Internet 
content liie most common form of URI is tiie Web page address, vMch is a particular form or subset of URI called 
a Uniform Resource Locator (URL), A URI typically describes tiie mechanism used to access tiie resource, die 
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specific computer that the resource is housed in and the specific name of the resource (typically a file name) on the 
computer. 

Clients and services (both may be implemented on devices as software and/or firmware) may be connected 
over the Internet, a corporate mtranet, a dynamic proximity network, within a single computer, or by other network 
connection models. The size and complexity of the devices supporting clients and services may range, for example, 
jfrom a snnple light switch to a complex, highly available server. Example devices inchide, but are not limited to: 
PDAs; cellular phones; notebook, laptop, and more powerful PCs; and more powerful computer systems, up to and 
including supercomputers. In some embodiments, the distance, latency, and implementation of cHents and services 
may be abstracted, with a common discovery and communication mettiodology, creating a *1>lack box" effect. This 
0 definition approach allows software unplementation issues to be dealt witibi by the underlying platform, yielding a 
loosely coupled systan that may be scaled to Internet proportions. 

The distributed computing environment may provide an Internet-centric programming model includmg 
WEB and XML content representation, dynamic device discovery, and secure de^dce communication tiiat is 
accessible from a wide range of networic devices. The distributed computing environment may include a network- 
15 programming model abstracted above the CPU level. The programmmg model may mclude the foUowing properties: 

• URI addresses ' 

• Strongly tipped data called content (addressed vwthURIs) 

• Substantially unlhnited amount of persistent content storage (e.g. stores), (contaming XML and non-XML 

content, such as that identified by MIME types) 
20 • SubstantiaUyunlunhed amount oftransient content memory called spaces (containing XML content) 

• Descriptive XML metadata (data about data) content advertisements that may be stored in a space to notif/ 
interested clients. 

• A substantially unlimited number of instructions (embodied as messages) 

• Secure message endpomts (gates) addressed by URIs 

25 • Data flow support (event messages) to coordinate work flow between distributed software programs 

Services and clients may run as programs vwthin the distributed computing environment Services may 
advertise theh capabihties to clients wishmg to use the service. CHents may or may not reside wifliin the same 
netwoik device, and that device's code execution environment may or may not support the Java platform. 

Using URIs to address content and message endpomts ^ves tiie distributed computing environment a 
30 powerfiil addressmg scheme. The address may specify the location of the content or endpoint, and may specify the 
route (or transport protocol) to be used. Items addressed using URIs also may have an associated security 
credentiaL The security credential may be used to control what clients are ^owed access to the item, as well as 
which operations authorized clients are allowed to perform on that item. 

The high degree of access provided by tiie distributed computing environment may be controlled by 
35 appropriate authentication and security systems and methods. Authentication and security in the distributed 
computing environment may include, but are not limited to: verifying tiie typing correctness of XML content in a 
message; securety identifying tiie sender to the receiver; a mechanism to check the integrity of messages sent from a 
client to a service and vice versa; and a mechanism of describmg a service's set of accepted messages to a client and 
enforcing the message requirements on messages received at tiie service. The above listed security and 
40 authorization features may be leveraged in a single, atomic unit of code and data. The atomic unit of code and data 

62 



wo 01/86394 



PCTAJSOl/15134 



may be dynamically created. In one embodimentj once created, the atomic unit of code and data may represent a 
message endpoint (gate), and may not be altered as to the security and authorization policies implemented during 
creation. 

A gate may represent the authority to use some or all of a service's capabilities. Each capability may be 
5 expressed in terms of a message that may be sent to a service. Gates may also be used for failure case detection 
when a client leases resources. 

Authentication and security may also include a mechanism for verifying that a client attemptmg to use a 
service is authorized to use the service; that the space from which the client receives the service advertisement from 
is authorized to provide the service advertisement; and/or that the service advertisement itself is authorized 
10 Message passing may be implemented in a messaging layer as the means of communicating requests from 

clients to services and of the services responding with results to tiie chents. The messaging layer of the distributed 
computing environment may substantially guarantee that valid XML messages are sent, and may provide 
mechanisms enabling a language-independent security model. In the messaging layer, a sending message enc^oint 
may be linked to a receiving message endpomt. The two associated message endpoints may provide a secure, 
15 atomic, bi-directional message channel suitable for request-response message passing between a client and a service. 

In embodiments of a distributed computing environment, an advertisement may be published in a space for 
a service. An advertisement may be an XML document that mcludes the XML schenm and XJRI of The 
service may also include a service ID token or credential in the advertisement, and may specify in the advertisement 
an authentication service to be used by both the client and the service. A client may then locate the service 
20 advertisement on the space, and use the advertisement to mstantiate a message gate on the client The client may use 
the authentication service specified in the advertisement to obtain an authentication credential for sending in 
messages to the client. In one embodiment, the client may pass the service ID token or credential from the service 
advertisement to the authentication service, and the authentication service may then use the service token or 
credential to generate the authentication credential for the client In one embodiment, the client may include a gate 
25 fectoiy that receives the necessary information to create the message gate, and the gate factory may construct the 
message gate and communicate with the authentication service to obtain the authentication credential for the client. 
A corresponding service message gate may be instantiated at the service. 

The client, at some point, sends a iBrst message to the service. In one embodiment, the client message gate 
may embed the client's authentication credential constructed by the authentication service id the message. When the 
30 service receives the message, it may use the same authentication service to verify the authentication credential 
received in the message. By sharing the same authentication service, any of a variety of authentication protocols 
may be employed, wifli the details of generating the authentication credentials separated from the client and the 
service. Thus, a client may use different authentication credential protocols witii dUBferent services. 

In one embodiment, the authentication service may determine tiie capabilities of the client (e.g. what the 
35 client is allowed to do on the service) upon Grst receiving the client authentication credential fit)m the service. The 
capabilities of the client may be bound to the client's identity. Then, the client's message gate may embed the 
authentication credential in every message sent from the client to the service. The messages may be received by tiie 
service message gate and then checked by the authentication service to ensure that the message is from the client and 
that the message request is within the capabilities of the client In another embodiment, the service message gate 
40 may handle capability determination and message checking for capabilities without using the authentication service. 
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The client and service message gates may work together to provide a secure and reliable message channeL 
The gates may serve as secure message endpoints that allow the client to run the service by sending and receiving 
secured, authorized XML messages to and from the service. 

Operations in the distributed computing environment may be embodied as XML messages sent between 
clients and services. The protocol used to connect clients with services, and to address content in spaces and stores, 
may be defined by the messages that can be sent between the clients and services* The use of messages to define a 
protocol may enable many dijQTerent kinds of devices to participate in the protocol. Each device may be to 
implement the protocol in a maimer best suited to its abilities and role. 

A service's capabilities may be expressed in terms of the messages the service accepts. A service's message 
set may be defiiied using an XML schema. An X3ML message schema may define each message format using XML 
typed tags. The tag usage rules may also be defined m the schema. The message schema may be a component of an 
XML advertisement along witiii the service's mess^e endpoint (gate) used to receive messages. Extensions (more 
capabiUties) may be added to services by adding messages to the XML message schema. 

In the distributed computing environment, authorized clients may be able to use all of a service's 
cq)abilities, or may be limited to usmg a subset of the service's capabilities. In one embodiment, once a set of 
capabilities has been given to a client, the client may not change that set without proper auAorization. This model 
of capability definition may allow for services levels that run from a base set of c^abilities to an extended set 

Service instantiation may be performed to allow a client to run a service. To instantiate a service, a client 
may first select one of the service advertisements published in a space. The client may use the various fecilities 
provided by the space to look up advertisements in the space. Then the client may request the space to mstantiate 
the service. Service instantiation may include, but is not limited to, the followiog steps: 

1. Client requests space service to instantiate a service. 

2. Space service verifies client is allowed to instantiate the service. 

3. Space service obtains, a lease on the service advertisement for the client with the lease request 
time specified by the client. Alternatively, the service advertisement may be provided to the 
cfient without using the leasing mechanism, 

4. Space service sends a message to the chent that includes the lease allocated in steps 3, and the 
service advertisement of the service. 

5. Client ruiis the authentication service specified in the service advertisement, and obtahas an 
authentication credential. 

6. Client constructs a client message gate for communicating with the service. 

In order to provide trust between clients and services in the distributed computing enviromnent, a series of 
dynamically generated nuinbers (keys, or tokens) may be used as security or authentication credentials for clients. 
One or more credentials may be used to verify the rigjit of a client to use a service and to verify messages between 
the client and the service- Each client and service may have a unitjueaedential. 

The type of authentication credential needed to use a service may be returned to the client conducting a 
service search. In one embodhnent, an authentication credential is an opaque object that must be presented each 
time a client uses a sendee. In one embodiment, the authentication credential may be presented by a message gate 
on behalf of a client in every message sent to a service. No matter what kind of authentication credential is required 
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by a service, by using an authentication service external to tiie client and the service, the client and the service may 
not need to be aware of the authentication credential structure or of the authentication process. 

An authentication credential may also include a transport-specific ticket in addition to the service ticket 
When running a service, depending upon the networking transport specified in the service advertisement, the 
5 transport may provide a secure connection. In some cases, if the data link layer is already secure, it may not be 
necessary to use a secure transport over the ah-eady secure data link lay«** 

The concept of an authentication credential is abstract enough to allow various levels of security based 
upon credential implementation. Levels of security may include, but are not lunited to: 

1 . None (no message security - credential is empty or no credential) 

10 Messages with empty credentials or no credentials may be sufQcientVfiien security is enforced 

by the physical connectivity properties of the transport For instance, a smart light switch 
connected to just one light switch controller is secure because the switches are wnred in a 
secure manner. 

2. Signed messages (digital signatures) 

15 Signed messages may include a digital signature that enables the service (receiving the 

message) to verify the origin (client) of the message. 

3. Encrypted messages (transport may handle tins) 

Encrypted messages add another level of security by scrambling the message contents so that 
another credentialis required to unscramble it 
20 4. Capability messages (service functionality and laser aware) 

This level of security may provide for security capabilities on a user-by-user basis (e.g. what 
the user is allowed to do), and may allow for fine-grained access control to services and 
individual service fiinctions. 
Multiple levels of security zones may be used, due to the heavyweight implementation necessary to aiforce 
25 the higher levels of security (c^abilitiies & encryption). H the message transport supports (or helps support) these 
security levels, the support may be leveraged to provide security level bridge services that bridge one level of 
security to another. 

As mentioned above, services without any security model may accept empty authentication credentials. For 
services that do not restrict access, a gate may be bvult without an authentication credential or with an "empty" 
30 authentication credential The gates for such services may not send an authentication credential with each message, 
or may send an empty credential The authentication service is one example of a service that may not restrict access. 
Other services may requure a user and password pair. 

Authenticating Service Access using Credentiak 

35 In some embodiments, a mechanism for verifying that a client attempting to run a service is an authorized 

client, for verifying that the service advertisement received by tiie client is an authorized service advertisement, 
and/or for verifying that tiie space from which the client received the service advertisement is authorized may be 
based upon a public key/private key asymmetric cryptographic mechanism, hi this mechanism, an aufliorized 
sending entity may embed a public key in a message and encrypt the message including the public key with its 

40 private key. An entity receiving the encrypted message may decrypt the message using the public key and find the 
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same public key embedded in the decrypted message, and thus verify that the message is from the authori2^d entity, 
since only that entity has the private key necessary to encrypt the message. Thus, an entity may issue a credential 
that is substantially unforgeabie, and that other entities may decrypt (with the appropriate pubUc key) to verify 
messages sent by the entity. 

5 Various key generation algorithms may be used m the distributed computing environment The 

composition of keys may be hidden from both cHents and services; thus, the cUent and service may not care what 
key generation algorithm is used. 

A Kerberos ticket is one example of a security credential that may be used in the distributed computmg 
environment Kerberos is a secure method for authenticating a request for a service in a computer network. 
10 Kerberos lets a user request an encrypted "ticket" from an authentication process that can then be used to request a 
particular service. The user's password does not have to pass through the network. 

Mechanisms may be provided by the distributed computing envfronment to substantially guarantee that 
messages sent between clients and services are not compromised In one embodiment, a sender may embed a token 
contaming information that may be used by the receiver to verify that the message has not been altered. There are 
15 several methods for generating the information to embed in the message. In one embodiment, a hash of the message 
may be conq>uted and sent with the message. Hashmg may include the transformation of a string of characters into a 
usually shorter fixed-length value or key that represents ^e origmal string. Upon receiving the message, the 
receiver may recompute the hash and check it against the sent hash. K the message has been altered, it is highly 
unlikely that the same hash will be generated. The sender may encrypt the hash and send the corresponding pubHc 
20 key in the encrypted message to substantially ensure that the hash is not compromised. 

In other embodiments, an error detection scheme such as cyclic redundancy checking may be used. Cyclic 
redundancy checking is a method of checldng for errors in data that is transmitted on a communications link. In an 
embodiment using cyclic redundancy checking, the sender apphes an n-bit polynomial to the message and appends 
the resulting cyclic redundancy code (CRC) to the message. The receiver applies &e same polynomial (which may 
25 also be passed in the message) to the message and compares its result with the result appended by the sender. If they 
agree, the message has been received successfiilly. If not, the sender may be notified to resend the message. 

Gate factories may also play a role in security, since a gate factory may be "trusted" code. Usmg a tmsted 
* gate factory to generate gates may help to ensure that gates are trusted code, and that the code is correct wth respect 
to the service advertisement Clients may be required to present a client ID token or credential to the gate factory as 
30 a means of authentication. Services m^ present a service ID token or credential to cUents (e.g. toough an 
advertisement) when a client wishes to create a gate. As discussed herein, a client and service token pair may be 
used to create a thfrd credential that may be used to aUow the cUent to send messages to the senice. This third 
credential may be referred to as an authentication credential An authentication credential may be created by an 
authentication service during the authentication process. In one embodiment, the service may use any authentication 
35 policy at its disposal. In one embodiment, the authentication service administers the authentication policy on behalf 
of die service, and dim the service does not have to be aware of the particular authentication pohc^ 

The cfient may construct its gate usmg an authentication credential that the client receives by nmning an 
audientication service specified m die service advertisement TTiis may aUow the constructed gate to send the 
autiientication credential witii each message to die service. When the service receives die first audientication 
40 credential in a first message from die cKent, die service may use die audientication service specified in die service 
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advertisement to authenticate the client, and thus may establish a binding of the authentication credential to the 
identity of the client ' 

As previously discussed, some results produced by a service may be advertised in a space and ultimately 
accessed using a results gate. The results gate may or may not contain the same security credential as the input gate 
5 used to generate the results. Because input to a service may be asynchronous firom its output (the results), the results 
may have a different set of access rights associated with it For example, a payroll service may allow a different set 
of clients to initiate payroll than to read the payroll service's results (p^checks). TTius, a client may have to go 
through a separate authentication process to obtain access rights to the results, which may include receiving an 
authentication credential for the results from an authentication service specified in an advertisement for the results. 
10 Message gates may offload most security checks fix>m services. Services may focus on providing capability 

and authenticating clients. A principle of least privilege may be supported by giving clients access to only those 
capabilities that are requested (or assigned). 

Security checks may occur when a gate is created and/or when a gate is used (when messages are sent 
and/or received). When a client requests access to an advertised item (service), the process of gate creation may 
15 begm. During this process, the client gate factory may work with the service to mutually authenticate each other. 
The checks performed at gate creation time may be extensive, and may minimize the numb^ of checks perfomied 
during gate usage. After the service has authenticated the client, the service may determine specific cc^jabiiides for 
the cUent (e.g. what the client is allowed to do on the service), and associate the capabilities with the cUenf s 
authentication credential. These specific capabilities may specify what operations the client is allowed to perform 
20 on the service. Since the gates may ensure that every message contains the authentication credential, the service can 
then check each request when it is received against the capabilities of tihie authenticated client 

Gate creation checks may ensure that a client has permission to use some or all of tiie service capabilities 
designated by the XML message schema. In one embodiment, these checks may be implemented using access 
conti-ol lists (ACLs) in conjunction with an authentication service such as Kerberos. A challenge-response sequence 
25 (such as a password) may also be used to authenticate a client In some embodiments, a hardware-based physical 
identification method may be used to authenticate the client For example, the user may supply a physical 
identification such as a smart card for identification and autiiorization. Otiier mechanisms for authentication may be 
used in other embodiments. 

In one embodiment, whatever means is used to authenticate the client, the authentication may be invisible 
30 to both the cMmt and service, the gate factory may be aware of \^ch authentication service to use, and the 
authentication service handles the authentication mechanism and policies. Gate factories may be product and 
environment dependent, or may even be controlled by a configuration management system. In one embodunent, the 
degree and method of client isolation may be platform dependent, but is known to the gate fectory. In some 
embodiments, a hardware-based physical identification method may be used to authenticate the client For example, 
35 the user may supply a physical identification such as a smart card for identification and authorization. Other 
mechanisms for authentication may be used in other embodiments. 

Message gates in the distributed computing environment are typically associated with a single client The 
gate factory may determine the means of association. The checks performed at message send time may ensure that 
the proper client is using the gate. In one embodunent, gates may be passed in messages, and may be cloned if a new 
40 client wishes to use the gate. The cloning process may perform anew set of creation checks. 
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Once a client of a space (the client may be another service) finds the advertisement of a space service, the 
client of the space may ixin the space service, as it would any other service. Running a space service may involve 
using an authentication mechanism. Running a space service may include, but is not limited to: 

1. The client of the space may first rim an authentication service that may be specified in the 
service advertisement of the space service to obtam an authentication credential 

2. The client of the space may use the authentication credential, the XML schema of the space 
(from spacers service advertisement), and the URI of the ^ace (from space's service 
advertisement) to construct a gate for the space. In one embodknent, the client may pass the 
information to a gate fectory to construct the gate. 

3. The client of the space may run the space service by using the gate to send messages to the 
service. 

4. When the space service receives the first message from the client, Avith the authentication 
credential embedded, the space service may use the same authentication service used by the 
cfient to obtain the authentication credential to authenticate the client, thus establishing the 
client's identity. 

5. The space service may then determine the clientfs capabilities (e,g. what the client is 
aUowed to do on the space service) and bind the capabilities to the authentication credentiaL 

As discussed in the Spaces section, a space's fecilities may include an interface for spawning an empty 
space with substantially the same functionality (same XML schema) as the space from which it is spawned. The 
spawning facility may be useful, among other things, for dynamically generating spaces for results. When a 
requestor has spawned a space, only the requestor may be allowed to access the spawned space. For example, tiie 
spawned space may be for storing results from a service that the client needs to keep secured. This security may be 
ensured by: 

• Creating an initial root authentication credential, and initializing the authentication service of the spawned 
space, so that the authentication service only authenticates the root authentication credential, and so that it 
returns no other authentication credentials (no other clients of the spawned space allowed initially). 

• Initializing the security poMci^ of tiie spawned space so that the root identity associated with the root 
authentication credential has access to all facilities of the space, including the security admimstration 
facilities. 

• Returning the root authentication credential and the service advertisement of the spawned space to the 
requestor of the spawned space. 

The requestor may build a gate to access the spawned space, since it is returned the authentication 
credential and the service advertisement of the spa\yned space. In one embodiment, only the requestor and clients or 
services that the requestor passes the authentication credential and the spawned space's service advertisement may 
access the spawned space. Such limiting of access to the spawned space may be usefiil when a client and service are 
using that spawned space to store results, for example, if the client and service deske to keep tiie results private. 

After running a service, the client may change the authentication policies of the spawned space using a 
security administration space fecility, and other clients or seryices may then access the spawned space. In addition, 
tiie spawned space's service advertisement may be made available to other clients of the spawned space (the other 
clieiits may be services) using the discovery protocol or other means. 
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The message transport layer in a distributed computing environment may include mechanisms for 
protecting the security and integrity of communications among clients and services during transport. This security 
may be referred to as "wire security" or "transport security" to distinguish it from the authentication security 
implemented by the messaging system including gates. Encryption of messages may be provided at the message 
5 transport layer of the distributed computing environment Services that request an encrypted transport may do so by 
tagging the XML advertisement The gate factory may then create a gate (or gates) that uses a secure message 
transport such as those provided by Bluetooth and BriTPS. 

HTTPS (Secure Hypertext Transfer Protocol) is a Web protocol that encrypts and decrypts user page 
requests as well as the pages that are returned by the Web server. HTTPS may use a multi-bit key size (may vary 
10 from 40 to 128- bit or more) for a stream encryption algorithm (e.g. RC4), to provide an adequate degree of 
encryption for commercial excliange. HTTPS may be used as a transport in the distributed computing enviroimiea^ 
Bluetooth is an emerging peer-to-peer wireless communications standard. The Bluetooth key generation 
algorithms may be used in the distributed computmg environment Bluetooth may support encryption keys. 
Encryption keys are transport dependent, while client, service, and combination keys may be transport mdependent 

15 

Figure 26a - An authentication service providing an authentication credential to a client 

Figure 26a is a flow diagram illustrating an authentication sendee providing an authentication credential to 
a chent according to one embodiment A client in the distributed computing environment may desire a service to 
perform one or more functions on behalf of the client In one embodiment, an authentication service may be 

20 provided for use by the client and the service when settmg up a secure messaging chamieL An authentication 
service may perfonri functions for the chent and/or service including authenticating the client and/or service and 
negotiating the desired level of security and the set of messages that may be passed between the client and service. 
The authentication service may be a process that is executing within the distributed computing environment The 
authentication service may be executing on the same device as the service and/or the chent, or alternatively the 

25 authentication service may be executing on a separate device such as an authentication server. In one embodiment, 
the authentication service may be an Internet-based seryice. The authentication service may have its own address, 
for example, a Universal Resource Identifier (URI), througji which tiie chent and/or service may communicate vsdth 
the authentication service. In one embodiment, the address of the authentication service may be provided to the 
client in the service advertisement for the service. The cUent and service sharing an authentication service may help 

30 insure that a secure messaging channel may be established between the client and the service, as any of several 
security and authentication protocols may be used in the messaging chatmel. 

In one embodiment, a chent may present a chent identification token or credential to an authentication 
service. The chent token or credential may be sufficiently unforgeable to be used as proof of the client's identity. 
The authentication service may then check the chent identification token or credential, and issue to the chent an 

35 authentication credential that only the authentication service can create. Ihe authentication credential that is 
returned to the chent is then sent m every message by the chent to the service. In one embodiment, the chent 
message gate is created by a gate fectoiy, which mcludes the authentication credential in the message gate, and thus 
the message gate includes the authentication credential in every message tiiat it sends to the service on behalf of the 
client When receiving a message, the service may then check the authentication credential. Since only the 

40 authentication service can create the authentication credential, flie service knows that the client did not forge the 
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authentication credential In one embodiment, the service may pass the authentication credential to the same 
authentication service used by the client to ensure the authentication credential is valid, to verify that the client is an 
authorized client, and to find out the identity of the client 

All services, including space services and authentication services, may authenticate their clients. Once a 
5 service authenticates a client, the client may access the iservice. For example, in the case of a space service, a client 
may then obtain XML advertisements from the space. 

In one embodiment, a service may have a prearranged credential that all clients of the service are to use. In 
this embodiment, the authentication may provide the prearranged credential to a requesting client. Any client 
presenting the prearranged credential to the service may be approved by the service. 
10 In step 1000, the client may request an authentication credential from the authentication service. In one 

embodiment, the client may search for and locate a service advertisement for the desired service. In one 
embodiment, tbe service advertisement m^ include an advertisement for the authentication service to be used to 
obtain an authentication credential to be used in accessing the service. In one embodiment, tire service 
advertisement may include an address such as a URI for the authentication service. In one embodiment, the client 
15 may send information to the authentication service requesting the authentication credential. In one embodiment, the 
client m^ send infonnation to a gate creation process, for example, a gate factory, and the gate creation process 
may access the authentication service to obtain tiie autiientication cred^tial. 

In step 1002, the authentication service may generate an authentication credential for the client The 
authentication credential may be a data element or data structure that may be embedded in messages in a messaging 
20 system and that may allow receivers of the messages to authenticate the sender of the message, to verify the message 
is from an authorized sender, and to verify that the message is a message the sender is allowed to send to the 
receiver. In one embodiment of a distributed computing environment, an authentication credential may be miique to 
the messaging channel set up between a particular client and a particular service. Step 1002 is further illustrated and 
described in Figure 26b. In step 1004 of Figiffe 26a, the authentication service may return the authentication 
25 credential to the cUent In one embodiment, the authentication credential may be returned directiy to the client In 
one embodiment, the authentication credential may be returned to a gate creation process, for example, a gate 
fectory, \\Wch may then use the authentication credential in generating a gate. 
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Figure 26b - An authentication service generating an authe ntication credential 

Figure 26b is a flow diagram expandmg on step 1002 of Figure 26a and fllustrating an authentication 
sendee generating an authentication credential accordhig to one embodunent In step 1002a, m one embodnnent, 
the authentication service may obtain a client token and a service token. In another embodnnent, the authentication 
5 service may obtain only a client token. In one embodiment, the client token may be a miique Identifier for the client 
in the distributed computing environment In one embodunent, the service token may be a unique identifier for the 
service in the distributed computmg environment For example, tiie pubUc keys from a pubHc/private key 
encryption mechanism may be used as unique identifiers for the client and the service. In one embodunent, the 
client may receive the service token m the service advertisement, and the cHent may provide the cHent token and the 
10 service token to the authentication service. \n another embodiment, the cUent may provide the client token and the 
service advertisement XJRI to the authentication service, and tibie autfientication service may retrieve the service 
token from the service advertisement 

In step 1002b, tlie authentication service may verify the client and/or the service. In one embodunent, the 
authentication service may use the client token and the service token obtained in step 1002a to verify the client 
15 and/or service. In anotiier embodunent, only a client token was obtained in step 1002a, and thus only the client 
token is used to verify the client in step 1002b. In one embodiment, the client may have pre^ously registered its 
cUent token with the authentication service, and the authentication service may compare the received client token to 
the registered client token to verify the chent as a valid cUent In one embodiment, tiie cUent may access the 
authentication service using a challenge/response mechanism such as a logon account with password and thus may 
20 be verified as a vaUd client hi one embodiment, the service may have previously registered with the authentication 
service, and may have provided its service token to the authentication service. The authentication service may then 
verify that the client is attempting to access a valid service by comparing the received service token to the previously 
registered service token. Other fypes of chent and service authentication may also be used. For example, tiie client 
may provide a digital signature or digital certificate that tiie authentication service may use to authenticate tiie cUent 
25 and/or to authenticate the service the client is trymg to access. 

In step 1002c, the authentication service may generate an authentication credential. In one embodunent, 
the autiientication credential may include an autiientication token that only the authentication service can create, hi 
one embodunent, tiie authentication service may use tiie cUent token and the service token in generating tiie 
authentication credential, hi another embodiment, tiie authentication service may use just tiie client token to 
30 generate tiie authentication credential, hi yet another embodunent, tiie authentication service may not use an 
obtained token in tiie generation of tiie authentication credential, but may instead use an authentication credential 
generation algorithm to generate a substantially unforgeable authentication credential. In one embodunent, tiie 
autiientication service may combme tiie service token and cli^t token to create a unique authentication credential 
For example, the service token and cUent token may be 64-bit values, and the two tokens may be combined to 
35 generate a 128-bit autiientication credential Other embodunents may use otiier metiiods to generate an 
authentication credential. 
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Bridging Devices to the Distributed Ne twork Environment 

There may be devices, external to the distributed computing environment, which do not support the 
message passing model implemented by the distributed computing enviromnent These devices may provide 
services that may be useful to clients in the distributed computing environment. The distributed computing 
5 environment may include a mechanism to bridge such external devices to the distributed computing environment so 
that clients in the distributed computing envkonment may access the services offered on such devices. The 
distributed computing enviromnent may also leverage existing device discovery protocols for discovering such 
external devices for use in the distributed computing environment 

Many technologies define discovery protocols for publishing and monitoring a networitfs device 
10 composition. These technologies include, but are not limited to: Jini, SLP, Bluetooth, and UPnP. Furthermore, 
mmy I/O buses such as LonWorks, USB and 1394 also suppwt dynamic discovery protocols. The distributed 
computing environment may leverage dcAdce discovery technologies by wr^p^ 

Leveraging other device discovery protocols and providing a method to bridge to other discovery protocols may 
allow the distributed computing environment to discover devices or services on a wide variety of network and I/O 

15 buses. Device discovery in the distributed computing environment may thus be applicable to a wide range of 
devices including smaU devices such as PDAs, even if they do not participate directly in the distributed computing 
environment Discovery protocols may be defined at the message leveL 

A bridging mechanism may be provided for *Svr^ping" one or more specific device discovery protocols, 
such as Bluetooth's, in a messaging API for the distributed computing environment Wrapping may include fi^g 

20 the device discovery protocol with code and/or data (the API) so that the protocol can be run by cHents and/or 
services in the distributed computing environment that would not otherwise be able to run it When run, the 
bridging mechanism may allow for a discovery agent that discovers devices by a specific device discovery protocol 
to publish services for those devices in a space in the distributed computing environment The services present an 
XML message schema interfece to clients in the distributed networic environment, and are capable of operating the 

25 various devices discovered by the specific device discovery protocol Thus, service advertisements may be 
pubUshed for the services that operate the various devices discovered by the underlying wrapped device discovery 
protocols. The advertised services Aus bridge devices (or services) external to the 

to clients on the distributed network environment 

Figure 27 illustrates one embodiment of a distributed coni5)uting environment with a space 1200. One or 
30 more discovery agents 1204 may participate in an external discovery protocol and bridge to the distributed 
computing enviromnent through bridging mechanism 1202, When the wrapped device discovery protocols are run, 
discovery agents 1204 teough bridging mechanism 1202 may publish service advertisements 1206a^l206c in space 
1200, wherein each one of advertisements 1206a-1206c corresponds to a device or service discovered by one of 
discovery protocols 1204 outside the distributed computing environment Clients may tiien access tiie external 
35 devices using the service advertisements 1206a-i206c in space 1200 to instantiate services on one of the agents 
1204 that operates the corresponding external device or service. 

Thus, clients of the distributed computing environment may use discovery ^ents wrappmg device 
<^covery protocols to find devices. A service acting as a bridge to these devices may be published in a space and 
advertised, so clients of the distributed computing environment may access the services provided by tire external 
40 devices. The advertised service is a service within the distributed computing environment that is able to invoke a 
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device outside the distributed compirting environment via another protocol or environment, thus bridging the outside 
device/service to the distributed computing environment. A cHent within the distributed computing envkonment 
"sees" only the advertised service wititiin the distributed computing environment and may not even be aware of the 
outside device/service. 

5 In one embodiment, the distributed computing environment may provide a version of a space discovery 

message protocol, such as the discovery protocol described in the Spaces section, that may be mapped to an 

underlying extemal device discovery protocol, including the wrapped device discovery protocols described above. 

The mapped discovery protocol may register itself or be registered with a space, e.g. a default space, by placing an 

advertisement in that space. For each advertised discovery protocol, a subsequent results space to hold the results of 

10 the discovery protocol may be provided. 

Figure 28 iUustrates an example of the space discoveiy protocol mapped to a Bluetoodi discovery 

1220 according to one embodiment The Bluetooth discovery service 1220 may first re^ster 1230 with the 
distributed computing environment The Bluetooth discovery service 1220 may be wrapped m a bridging API, and 
an advertisement 1225 for the discovery service 1220 may be added 1232 in space 1224. A client or service may 
15 locate die discovery service advertisement 1225 on space 1224. When the discovery service 1220 is executed 
(utilizing the API wrapper as a bridge between the discovery protocol 1220 and the distributed computing 
environment 1222), a new space 1226 may be created 1234 to store the results of the discovery process. The 
discovery service 1220 may store the results (again through the API wrapper) to discovery results space 1226 as one 
or more advertisements 1227. Alternatively, results of executing discoveiy service 1220 may be stored to space 
20 1224 or other pre-existing spaces m the distributed computing environment A sinular method as illustrated in 
Figure 28 may be used to discover devices and other services using other underlying discoveiy protocols. 

As mentioned above, diere may be devices, external to die distributed network environment, winch do not 
support the message passing model implemented by die distributed network envhx)nment These devices may have 
cHents that may want to use services provided in the distributed computing envhonment The distributed computmg 
25 environment may provide a mechanism to bridge the external cUents or cUent devices to the distributed computing 
environment so that die cHents on die external devices may access services m die distributed computing 
environment 

Agents may be provided diat serve as cHents in the distributed computing environment to bridge external 
clients to the distributed computing environment, allowing the external clients to access services pubUshed in the 

30 distributed computing environment In one embodunent, an agent may have an XML-enabled back end capable of 
communicating with services in the distributed confuting environment using die message passing model, and a 
proprietary protocol (e.g. a protocol si^^ported by die external device) on die front end to interfece to the external 
device, and thus to die external client Thus, a client external to die distributed computing environment may locate 
and access services in die distributed computing environment dirough die bridging agent, and may send requests to 

35 die services and receive responses from die services, including results data. For example, an external client may use 
die bridging agent to run space discovery in die distributed computing environment, look up advertised services, and 
invoke services in the distributed computing environment 

In one embodiment, die distributed computing environment may provide a bridgmg mechanism for 
accessing Jhu services from a distributed computing envux)nment cUent Smce Jini services may require Remote 

40 Mediod Invocation (RMT), and since clients in the distributed computing environment may communicate to services 
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Tising messages such as XML messages, a protocol bridging mechanism may be provided to enable the access of a 
Jini Service by a distributed computing enviroraBcnt client In one embodiment, a comiector mechanism may be 
defiBed that enables the dynamic advertisement of Jini services in distributed computing environment spaces, and 
that also may enable the accessing of a Jini service proxy from clients m the distributed computing environment In 
5 one embodiment, there may be Jini services that may not be bridged to the distributed computing environment. 

Li one embodiment, an agent may be provided as a service in the distributed cpmputmg enviromnent that 
bridges the Jini RMI protocol used by Jini services to XML me$saging used by distributed computing environment 
clients. When the agent is started, the agent may perform a lookup on the Jini spaces for Jini services that have a set 
of attributes. For every registered Jini service, the agent may generate an XML advertisement that may correspond 
10 to the service and may register the advertisement in a space in the distributed computmg environment In one 
embodiment, an agent may register for evait notification in the Jini Lookup service, and thus m^ be informed vAiesx 
a new Jini service is registered. When informed of a new Jini service, the agent may perform a lookup in Jini spaces 
to locate newly advertised Jini services and to update the distributed computing environment space witii new XML 
advertisements for the new services. In one embodiment, when a Jini service is removed, the agent may receive an 
15 event notifying of the removal of the Jini service. The agent may then remove the XML advertisement for the 
service from the space- 
In one embodiment, to invoke a Jini service via an XML advertisement in a distributed computing 
environment space, a client may look up the service advertisement in the space and may send vaUd messages to the 
agent to access the service. The agent may invoke the proxy service corresponding to the Jini service by invokmg 
20 the corresponding method through an RMI call to a service proxy. If tiie proxy is not instantiated, the agent may 
download the proxy code and instantiate a new mstance of the proxy object In one environment, every client 
connection may have a different proxy-instance. The incoming message from the client may be converted by the 
agent mto a method call for the proxy. The result from the method call may be returned to the cHent as an outgoing 
message. 

25 In one embodiment, only simple Java types may be used as arguments to an RMI method. If complex Java 

types are required, then one or more data advertisements may be passed as arguments to the call, where the data 
advertisements may indicate the location and access method of data for the ciDmplex Java types. In one 
embodiment, the agent may perfonn initial conversion from XML messages to an RMI method call mvocation 
dynamically. Since, the agent knows the service interface, it may generate the corresponding set of messages that are 

30 advertised to the client 

Figure 29 illustrates bridgmg a client 1250 external to the distributed computing environment to a space 
1254 in the distributed computmg environment Bridging agent 1252 may serve as the go-between between client 
1250 and space 1254. Bridging agent 1252 may communicate with client 1250 in a communications protocol 
understandable by the client 1250. Bridging agent 1252 may map the client's communications protocol into the 

35 XML messaging protocol necessary to conamunicate whh space 1254 perform the fecilities provided by space 1254. 
Bridging agent 1252, at client 1250*s request, may locate and run services on space 1254. For example, client 1250 
may request a list of all services of a particular type from space 1254. Bridging agent 1252 may locate service 
advertisements 1256a-c and return tijie results to client 1250. Alternatively, ^e results may be posted in a results 
space, and the location of the results may be returned to the client 1250. Client 1250 may then choose to execute 

40 service advertisement 1256a, and may send a message (m the client 1250's communications protocol) to bridging 
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agent 1252. Bridging agent 1252 may then send the XML request message(s) necessary to execute the service 
represented by service advertisement 1256a, and may return the results of the service to client 1250. Methods of 
handling the results of the service other than dhectly returning the results to the client 1250 may be used as 
described above in the section titled Spaces, Bridging agent 1252 thus may act as a service of the external client 
1250 (via the external client's protocol) and as a client within the distributed computing environment to bridge a 
service within the distributed computing environment to the external client 

Sometimes, even within the distributed computing environment, clients and services cannot directly 
communicate with each other, only to a common space. In this case, the space service will automatically create a 
service proxy that bridges client to service. The proxys main job is to route messages between client and ser\dce 
through the space. The service proxy may be created dynamically. The creation mechanism may be dependent 
upon space implementation. Refer to Figure 30 for an illustr^on of a proxy mechanism. A client 554 and a service 
556 m^ not be able to communicate directly within distributed computing environment, e.g., because they 
support different transport or network protocols. However, they both may be able to communicate with a space'*552 
that supports both protocols. The space service may create a proxy 550 to bridge the client 554 to the service 556. 
A common foim of proxy is a browser proxy. A browser proxy (most commonly implemented as a servlet) may 
translate conventional Web page requests mto messages. Refer also to the description of space search services (and 
proxies therefore) in the Spaces section herein. 

The distributed computing environment may provide a mechanism for bridging cUents in the distribirted 
computing environment to enterprise services. In one embodiment of a distributed computing environment, a 
method for bridging clients to enterprise services may include a client within the distributed computing envhonment, 
a bridge service within the distributed computing environment, and an enterprise service vnthin the enterprise 
environment. The distributed computing environment bridge service serves as a bridge service between the client 
and the enterprise service. An enterprise may be a corporation, small busmess, non-profit institution, government 
entity, or otiier kmd of organization. An enterprise may utilize an enterprise computing environment for conducting 
a portion of its business. The enterprise computing environment may include various enterprise sendees. Clients in 
the distributed computing environment may desire to use services in the enterprise computing environment An 
enterprise service may be based on a number of architectures, such as three tiered client/server architectures. An 
example of an architecture that may be used to implement an enterprise service is Enterprise JavaBeans. Enterprise 
JavaBeans (EJB) is an architecture for setting up program components, written in the Java programmmg language, 
tiiat run in the server parts of a enterprise environment using a client/server model. In object-oriented programming 
and distributed object technology, a component is a reusable program building block that may be combined with 
otiier components m tiie same or other computers m a distributed network to form an application. EJB is buih on the 
JavaBeans technology for distributing program components (Beans) to clients in a network. To deploy an EJB Bean 
or component, it must be part of a specific application, which is called a container. In Enterprise JavaBeans, there 
are two types of beans: session beans and entity beans. An entity bean is described as one tiiat, unlike a session bean, 
has persistence and can retain its original behavior or state. Using EJB, programs may be deployed across 
substantially all major operating systems. EJB's program components are generally known as servlets (little server 
programs). The application or container that runs the servlets is sometimes called an application server. 

The bridge service interacts with the client via XML message passing to gather input parameters necessary 
to make requests to the enterprise service outside of the distributed network environment For example, the bridge 
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service may be looked up and instantiated by the client just as any other service in tiie distributed computing 
environment The bridge service then may interact witii the enterprise service to run the enterprise service. This 
interaction may use an mterprocess communications architecture that the enterprise service can understand. As an 
example, if an enterprise service is implemented with Enterprise JavaBeans (EJB), a bridge service may 
5 communicate witii the enterprise service using EJB. The bridge service may to receive resdts from the enterprise 
service and may return the results directly to the client (in XML messages) or may place the results in a space in the 
distributed network environment (e.g, a results space). To the cUent, the bridge service ^pears to be the only 
service (the enterprise service is hidden to the client), so the client does not have to support the architecture of the 
enterprise service/ Multiple distributed network environment cHents may use the same bridge service (each usmg a 
10 unique gate pair) to interact with the enterprise service. 

The bridge service or other agent may publish an advertisement for the bridge service (and Aus for the 
enterprise service) m a space in the distributed computing environment For exanq)le, a bridge service or other 
bridge agent may use Java Reflection to examine Beans for services in an enterprise system implemented with EJB, 
and then CTeate service advertisements for bridge services to the Beans and publish those advertisements in spaces in 
15 the distributed computmg environment. Reflection is a metiiod for Java code to discover information about the 
fields, methods and constructors of classes, and to use reflected fields, methods, and constructors to operate on their 
imderlying counterparts on objects, withm security restrictions. The Reflection API accommodates plications that 
need access to either the pubUc members of a target object or the members declared by a given class. Once the 
bridge services are advertised, clients may access the bridge services (and thus the corresponding enterprise 
20 services) suniiarly to any other advertised services in the distributed network environment 
architecture of the enterprise service providing the services. 

Client Displays 

There are several metiiods in vvlxich results from a service run by a client may be displayed in a distributed 
25 computing environment Devices tiiat may display results may include, but are not limited to: CRTs on computers; 
LCDs on laptops, notebooks displays, etc; printers; speakers; and any other device capable of displaying results of . 
the service in visual, audio, or odier perceptible format The methods for displaying results may inchide, but are not 
limited to: 

• The service may return results to a client directly or by reference, and the client may handle the 
30 display of the results. 

• The service may return results to a client directly or by reference, and the client may pass the 
resulte to a display service directiy or by reference, and the display service may display the results, 

• The service may directiy handle the displaying of the results. 

• The service may pass the results to a display service directiy or by reference, and the display 
35 service may display the results. 

Iq tiie last method of displaying results, the client may specify the display service. For example, there may 
be a display service on or associated with tiie device on which the client resides tiiat tiie client wishes to use to 
display the results of the service. When the client runs the service, the client may send a message to the service 
specifying the service advertisement of the cUent's display service. The service may then build a gate that allows it 
40 to send messages to the client's display service. Thus, when displaying results, tiie service invoked by die client 
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becomes a client of the client's display service and sends its results (directly or by reference) for display to that 
(fcplay service. More detail on the client-service relationship, gates, and messaging is included in other sections of. 
this document 

Conventional appUcation models are typicaUy based on predetermined, largely static user int^^ 
5 data characteristics. Changes to conventional applications may require code modification and recompilatioa The 
mechanisms described for advertising services and for specifying XML message scheraas for communicating with 
services m the distributed computing environment may be used to provide a mechanism for applications (clients, 
services, etc) to describe dynamic display objects. Using the dynamic display objects, application behavior may be 
altered without having to download new code, recompile, or re-link the application. Display schemas may be 
10 provided for displaying the same results in different fonnats, for extract^ 
for displaying the results on different display devices. 

Figure 31 illustrates one embodhnent of a client 1300 with associated display 1302 and display service 
1304 according to one embodiment An advertisement 1306 for display service 1304 may be registered on space 
1308. An advertisement 1312 for service 1310 may be registered on space 1314 by service 1310. Alternatively, 
15 service advertisement 1312 and display service advertisement 1306 may be registered on the same space. Client 
1300 may search for and discover (1320) service advertisement 1312 on space 1314, and may then set up a gate to 
send requests to (and rweive results or responses from) service 13 10. In one embodhnent, the messages may be in 
the form of XML messages specified in an XML schema received as part of advertisement 1312. Ghent 1300 
send one or more messages (1322) to service 1310. The one or more messages may mclude messages for runnmg 
20 service 13 10 and for instructing service 1310 to send results to display service 1304 for display, and may specify the 
location of display service advertisement 1306. The advertisement location may be specified as a Uniform Resource 
Identifier (URI)- 

The messages from client 1300 to service 1310 may mstnict service 1310 to perform one or more 
operations Aat produce displayable results. Service 1310 may retrieve display service advertisement 1306 from 
25 space 1308 based upon the location mformation received from client 1300. The service advertisement may include 
the XML message schema and other information necessary to interface with thsplay service 1304. Service 1310 
may then set up a gate to send requests to (and receive results from) display service 1304. In other embodiments, 
messages from cUent 1300 to service 13 10 may mclude the XML schema and other information needed for service 
1310 to construct a gate to display service 1304, or may include a pre-constructed gate to display service 1304. 

30 During, or after completing, operations requested by client 1300, service 13 10 may send the results of the 

operations to display service 1304 in the mamier specified by the schema for display service 1304 (e.g. encapsulated 
in XML messages specified in the XML message schema or by reference as parameters for the display service). In 
tius regard, service 1310 may be a client of display service 1304. Display service 1304 may then format and display 
the results received from or mdicated by service 13 10 oil display 1302 for the client 

35 In some embodunents, service 1310 may post the results of operations to a space such as a results space 

(not shown). Service 1310 may then send a message to display service 1304 mcludmg a reference to tiie stored 
results of tiie operations. In one embodiment, the reference may be in the form of a URI. The display service 1304 
may then retrieve the results from the space and display the results on display 1302. * 

* Conventional application models are typically based on predetermined, largely static user interface and/or 

40 data characteristics. Changes to conventional applications may require code modification and recompilation. The 
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mechanisms described for advertising services and for specifying XML message schemas for communicating with 
services in the distributed computing environment may be used to provide a mechanism for applications (clients, 
services, etc) to describe dynamic display objects. Using the dynamic display objects, application behavior may be 
altered without havmg to download new code, recompile, or re-link the application. 

The dynamic display objects may be described in XML schemas. These schemas may be advertised in 
spaces. These schemas may be refeired to as display schemas or presentation schemas. An application (or other 
services acting on behalf of the application) may then access the schemas from the service advertisements to display 
data based upon formatting, data type, and other information stored in the schemas- 

The following is an example of a schema contammg dynamic display objects: 

<element name=="delivay" type="Space3hipto" minOccurs="0** /> 

<type name="TextField"> 

<element name^" Address" typeF="string"/> 

<element name="City" type="string"/> 

<element name="State" type="string"/> 



</type> 

The above schema may be changed to the following without requiring an ^plication recompile; 

<element name="delivery" type="Space:shipto" minOccurs="0" f> 
<type name="TextField**> 

<element name=*'Name" type=="string"/> 

<element name-'Address" type="string"/> 

<element name="City" type- 'string"/> 

<elementname- *State" type="string"/> 



</type> 

Figurcs 32A and 32B illustrate examples of using schemas of dynamic display objects according to one 
embodiment In Figure 32A, application 1320 (may be a client, a service, or other application) has been 
implemented with presentation schema advertisement 1324 stored in space 1326. A presentation schema 
advertisement may include elements describing the data types, formatting specifications, fonts, locations, colors, and 
any other information used for displaying data for the ^Hcation on displ^ 1322. There be multiple 
presentation schema advertisements for application 1320. For example, feere may be one schema for each display 
page in a series of displ^ pages (for example, Web pages on a Web site). 
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In one embodiment, application 1320 may invoke a discovery and/or lookup service to locate presentation 
schema advertisements. Hie discovery and/or lookup service may return an XML document listing one or more 
advertisements, and URIs to each of the schemas describing a particular display format, etc. Application 1320 may 
then select a presentation schema or schemas from the XML document Application 1320 may then parse the 
5 schema, breaking out the elements of the schema into user interfece components. The components then may be used 
to locate! format, and display resutts data on the appropriate display. Ihe result data may be finm ranning a service 
or from a results space, for example. Thus, as opposed to having a static or predeteimmed display, the application 
1320 is configured to display results according to a presentation schema that may be dynamically changed vvithoiit 
requiring a rebuild of the appUcatioru 
10 Presentation schemas may be provided for displaymg the same results in different fonnats, for extracting 

portions of the results for displ^, and for displaying the resuhs on differait display devices. 

In one embodhnent, one or more pigmentation schema advertisements may be stoed in one or more ^aces 

in a distributed computing environment. As copies of an appUcation are invoked on one or more devices, each copy 
of the application may run a search for services to discover advertisements for the presentation schemas used by tiie 
15 appUcations. Thus, a central, persistent store of tiie display information may be kept for multiple instances of the 
sqjplication or for oflier applications. The display information may be modified in tiie central location wilhaut 
requirmg therecompilation ar»d/or reinstallation of flie applications. 

In Figure 32B. client 1328 may locate a service advertisement for service 1330 on a space. When invokmg 
service 1330. cUent 1328 may pass a location of presentation sdiema advertisement 1324 on space 1326 to service 
20 1330. When service 1330 is ready to provide results to cliem 1328, it may display the results on display 1322 
(which may be coupled to the device on which client 1328 is running) using the display information from the 
presentation schema provided by presentation schema advertisement 1324. To change the way tiie results are 
displayed, the XML messages in ttie presentation schema advertisement 1324 may be modified, or a different 
presentation schema may be selected, without requiring changes at the cUent 1328 or service 1330. Service 1330 

25 may be a display service. 

A cUent, application or service may provide a pluraUty of display schemas for displaying results of various 
operations provided by one or more services. Alternatively, a display schema may include inforaiation fer 
displaymg a variety of results for one or more clients. Thus, client 1328 may use one display schema or a plurality of 
display schemas. Two or more display schemas may be provided for formatting and di^laying the same results wifli 

30 different formats, or on different displays. For example, one display schema for a set of results may be provided for 
displaymg results on a display screen, and another for printing the results. Also, copies of tiie same appUcation, 
cUent or service may nm on devices wifli different display capabilities, so two or more display schemas may be 
provided for supporting tiie display requirements pfflie differait devices. 

35 String Management 

Strmg handling in conventional systems is generally not very efficient espedaUy for variable 
and may be wasteM of memory space, e.g. as flie string is copied and/or moved m memory. This inefficiency in 
string handling may be particularly problematic in small memory footprint systems such as embedded Systems. The 
amount of memory, particularly stack space and space for dynamic allocation, may be limited in small footprint 
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systems. Tlius, a more efficient method of handling strings in programs executing withm small footprint systems 
such as embedded systesms is desirable. 

Figure 33A illustrates a ^ical string representation in flie C programming language. In C. a string may be 
represented by a character pointer 1450 (stringl) containing a memoir location (address) of the first character of a 
5 stringl452. Other characters follow the first character in the string 1452, and are ty^^^^ 

addressable byte locations in memory. Characters in C strings are typically 8-bit ITie characters m C strings may 
be any ASCT character. A C string must be terminated by a NULL character. NULL is platfoim defined as one of 
Ae 256 possible 8-bit values, but is typically the binary value ObOOOOOOOO. -me string 1452 occupies 13 bytes (12 

string characters plus the temunating character). 
10 An example of a string operation in C is the strknOfiinction,typicany provided 

implementations. The strlenQ fimction takes a string pointer as input and returns tbe length (in bytes) of the string, 
not including the terminating character. For example, passing fte character pomter 1450 to the strlenQ fimcticm 
would retum flie length 12. The strlenQ fimction may be implemented by "walking" the string until the terminating 
character is located, counting each character. 
15 String copying in C is typically handled by a strcpyQ or a sUncpyO C hbraiy functions, which are 

implemented as: 

char *strcpy(char *dest, const char *src); 
char ♦stmcpy(char *dest, const char *src, size_tn): 
The StrcpyQ toction copies the string poiiited to by the character pointer src (includmgfhe terminating character) to 
20 the string pointed to by character pointer dest . The strings may not overlap, and fte destination siring dest must be 
large enou^ to receive the copy. 

The stmcpyO &nction is similar, except that not more thannbytes of src are copied. Thus, if there is no 
terminating character among the first n bytes of src, the result will not be tetmmated. If desired, an mstrucUonmay 
be placed m the code following a stmcpyQ to add a termination character to the end of the dest string. In the case 
25 where the length of src is less than that of n. the remainder of dest will be padded with nuUs. Ihe strcpyQ and 
StmcpyQ functions return a pomter to die destination string dest . 

Figure 33B illustrates an example of the results of the stmcpyQ fimction on string 1452, when stmcpyQ is 
called with the following parameters: 

30 stincpy(string2, stringl+3. 5); 

where stringZ is character pointer 1454 pointing to the first byte afier the terminating character of string 1452, 
stringl+3 is characterpointer 1450 incremented by 3 bytei^ and 5 is the number of charact^ 
fit,m the source location stringl+3 to string2. After copying, the next character after the five characters copied fi:om 
35 stringl may be set to die terminatmg character (the char^ may have been initialized to the terminatmg character 
prior to the copy). Thus, the two strings now occupy (13 + 6) = 19 bytes of memory. If the strcpyQ fimction was 
appUed with character pointer 1450 as the source string, the origmal string 1452 

ocaq>y.(13*2) = 26bytes. ■ . 

Figure 33C illustrates an efficient method for representing and managmg strings m general, and in smaU foo^rint 
40 systems such as embedded systems m particular. Sfring 1452 is stored m memory as 12 bytes (no terminating 
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character is required). String structure 1460 includes pointers (Address(A) and Address(L)) to the first and last 
characters of string 1452. Using this string structure, the string's lengfti may be efBciently computed by subtracting 
the pointer to the first character fiom the pointer to the last character. 

Operations such as string copy operations strcpyQ and stmcpyO may also be handled more efficiently. 
5 With string structures such as those illustrated in Figure 33C. a new string structure 1462 may be created, and the 
first and last character pointers may be initialized to point to the respective characters in string 1452. Thus, a 
portion or aU the string 1452 does not have to be copied to new storage for the string. As strings can be hundreds or 
even thousands of characters long, the memory saved using the string structures and string mediods in^)lemented to 
take advantage ofthem may be considerable. This raethodof handling copiesof portions or all of a string may be 
10 caUed"substringmanagement,**asitdealswiththeeffidenthandlingofportions^^^^^ 

Other string fimctions fixsm the standard C string library niay be replaced with string fimctions taking 
advantage of flie string structure as illustrated m Figure 33C. Examples of other C string functions include, but are 
not limited to: strstrQ, strcatQ^ and sprintfQ, The string handling structures and methods as described in Figure 33C 
may be used, along with the hierarchical structure of XML documents, to provide more efficient handlmg of XML 
15 text (such as XML messages) m systems witii small memory footprints such as embedded syst^. The followmg is 
a simple example of an XML schema defining a purchase orden ? 

<lDOCTYPEpurchase.order SYSTEM "po.dtd"> 

<purchase.order> 
<date>22 May 2000</date> 
20 <billmg.address> 

<name>John Smith</name> 
<street>l23 Main</street> 
<city>Anywhere</city> 
<state>MA<ystate> 
25 <2ip>12345-6789</zip> 
</billing.address> 
<items> 
<item> 
<quantity>3</quantity> 
30 <product.number>248</productnumber> 

<description>Decorative Widget, Red, Large</description> 

<unitcost>19.95<yunitcost> 
</item> 
<iten£> 

35 <quantity>l</quantily> 

<productnumber>1632</productnumber> 
<descriptLon>Battery, AA, 4-pack<;/descriptiotf> 
<unitcost>4.95<yunitcost> 
<yitem> 

40 <Vitems> 

<ypurchase . order> 

The hierarchical structure of XML documents may allow tiiem to be processed in a reciursive feshion widi 
successively smaller portions of the document processed at each level of recursion. References to various portions 
45 are recorded and processed recursively. String structures as described in regard to Figmre 33C may be used to 
record tiie various portions. In tiiis manner, tiie content of specific XML tags (one line in the above wcample), m 
one embodiment die smallest unit of tiie XML document processed recursive^, may be determined efficiently. 
Documents witii repeated tags in tiie same scope may also be handled efScientiy, as tag^ within a given scope may 
be enumerated and processed efticientiy. 

81 



wo 01/86394 



PCTAJSOl/15134 



A recuisive method for processing an XML document using string structures similar to those described in 
Figure 33C may accept a string structure representing the entire XML document string and pointing to the first byte 
and the last byte in the document string. The method may then locate the next subsection of the document and pass 
a string structure representmg the substring of the entire document string containing the subsection to a processing 

5 fonction for the subsection type. The subsection itself may be broken into another level of subsections represented 
by string structures passed to processing fimctions for the subsection type. The method may continue in the 
recursive processmg of the XML document subsections \mtil the entire document has been p^^ 

Using the string structures with the recursive processing allows the processing to be done without creating 
copies of the subsections for processing. Copying of subsections may be particularly costly in recursive processmg, 

10 because as the recursion goes deeper, more and more copies of the same data are made. Using the string structures, 
only the string structure containing the pointers to the jSrst and last bytes in the subsection needs to be created and 
passed down to the next level Other operations, such as determining the length of a subsection, vasy be performed 
efficientiy using the address iirFoimation stored in tiie string structures. Also, by using the string structures, 
terminating characters such as those used to terminate C strings are not necessary, conserving memory in small 

15 foo^rint devices such as embedded devices. 

XML representation of Objects 

As previously mentioned, Jini RMI may not be practical for some clients, such as thin clients with minimal 
memory footprints and mfaiimal bandwidtL The serialization associated with tiie Jini RMI is slow, big, requires the 

20 JVM reflection API, and is a Java specific object representatioiL Java deserialization is also slow, big and requires 
a serialized-object parser. Even Java based thin clients may not be able to accept huge Java objects (along with 
needed classes) being returned (necessarily) across the network to the client, as required in Jini. 

A more scalable distributed computing mechanism may be provided by embodiments of a distributed 
computing environment A distributed computing environment may include an API layer for fecilitating distributed 

25 computing. The API layer provides send message and receive message capabilities between clients and services. 
This messaging API may provide an interface for simple messages in a representation data or meta-data format, such 
as in the extensible Mark-up Language (XML). Note that while embodiments are described herein employing 
XML, other meta-data type languages or formats may be used in alternate embodiments. In some embodiments, the 
API layer may also provide an interface for messages to communicate between objects or to pass objects, such as 

30 Java objects. Objects accessible through API layer 102 are represented by a representation data format, such as 
XML. Thus, an XML representation of an object may be manipulated, as opposed to the object itself 

The API layer may sit on top of a messa^g layer. The messaging layer may be based on a representation 
data format, such as XML, In one embodiment, XML messages are generated by the messaging layer according to 
calls to the API layer. The messaging layer may provide defined static messages that may be sent between clients 

35 and services. Messaging layer m^ also provide for dynamically generated messages. In one embodiment, an 
object, such as a Java object, may be dynamically converted (compiled) into an XML representation. The object 
may include code and/or data portions. The object's code and/or data portions may be compiled into code and data 
segments identified by XML tags in the XML representation. .The messa^ng layer may tiien send the XML object 
representation as a message. Conversely, the messaging* layer may receive an XML representation of an object The 
40 object may then be reconstituted (decompiled) fi-om that message. The reconstitution may exaunne the XML 
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representation for tags identifying code and/or data segments of the XML representation, and use information stored 
in the tags to identify and decompile the code and/or data portions of the object. 
Creating and sending an XML representation of an Object 

Figure 34 illustrates aprocess of moving Java objects between a client 1500 and a service 1502 according 
5 to one embodiment Service 1502 may be any service supported in the distributed computing enwonment, 
including space services. Client 1500 employs a gate 1504, which may have been created using an XML schema 
received from a service advertisement for service 1502, to communicate vnth a coiresponding gate 1506 for service 
1502. At some pomt, client 1500 may need to send Java object 1510 to sendee 1502. Java object 1510 may 
reference other objects, which may in turn reference other objects, and so on. Java object 1510 and its referoiced 
10 objects, the objects they in turn reference, and so on, may be refored to as an object graph. 

Java object 1510 may be passed to a Java object compilation process 1512 to be conq)iled to produce an 
XML representation ofthe object graph. The XML representation of the object gr^h m^ be passed as an XML 
data stream 1514 to gate 1504. The XML data stream 1514 may include an XML representation of aU Ae objects m 
the object graph In one embodunent, the objects in the object graph may be stored recursively in &e XML data 
15 stream 1514. 

Gate 1504 may then package the XML data stream 1514 in a message 1516 and send the message 1516 to 
gate 1506 of service 1502. Gate 1506 may extract the XML data stream 1514 from XML message 1516 and send 
the XML data stream 1514 to an XML data stream decompnation process 1518 to be decompiled to produce the 
object(s) comprising the object graph, including Java object 1510. In one embodunent, the objects in the object 
20 graph may be stored recursively m the XML data stream 1514, and thus a recursive decompilation process may be 
used. 

When service 1502 needs to send a Java object to cHent 1500, a substantially shnilar process may be used. 
Java object 1520 may be passed to a Java object compflation process 1512 to be compiled to produce an XML 
representation of the object graph. The XML representation of the object graph may be passed as an XML data 
25 stream 1522 to gate 1506. Gate 1506 may then package frie XML data stream 1522 in a message 1524 and send the 
message 1524 to gate 1504 of cUent 1500. Gate 1504 may extract the XML data stream 1522 from XML message 
1524 and send the XML data stream 1522 to an XML data stream decompilation process 1518 to be decompiled to 
produce the object(s) comprismg the object graph, includmg Java object 1520. 

hi anoAer embodiment, the gates may be responsible for the compflation and decompilation of Java 
30 objects, hi this embodiment, Java object 1510 may be passed to gate 1504. Gate 1504 may then pass object 1510 
to a Java object compilation process 15 12 to be compiled to produce an XML representation of the object graph m 
an XML data stream 1514. Gate 1504 may tiien package tiie XML data stream 1514 in a message 1516 and send 
tiie message 1516 to gate 1506 of service 1502. Gate 1506 may extract the XML data stream 1514 from XML 
message 1516 and send the XML data stream 1514 to an XML data stream decompilation process 1518 to be 
35 decompfled to produce the object(s) comprising the object graph, mcluding Java object 1510. The process of 
sending a Java object fixim service 1502 to client 1500 inay be substantiaUy similar to the process of sending an 
object from die client to the service. 

hi one embodiment, object compflation process 1512 and object decompilation process 1518 m^.both 
exist on the client 1500 and the service 1502, and may be programmed to perform compflation and decdmpilation 
40 substantiaUy similarly on the two devices, thus ensuring the object(s) output on one end are substantially identical to 
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&e object(s) input on the other end. In one embodiment, XML schemas including descriptions of Java objects may 
be used on both the client and/or the service in the compilation and decompilation processes- fa one embodiment, 
XML schema(s) to be used in the compilation and decompilation of Java objects may be passed by the service to the 
client in the service advertisennent. 

XML provides a language- and platfonn-independent object representation format. Thus, the process as 
illustrated m Figure 34 where an object is compiled into an XML representation of the object and decompiled to 
reproduce the object may not be limited to movmg Java objects, but in some embodiments may be applied to 
moving objects of other types between entities in a network, 

JVM compilation/decompilation API 

Figures 35a and 35b are data flow diagrams illustrating embodiments vAicxe a virtual machine (e.g. JVM) 
includes extensions for compiling objects (e.g. Java Objects) into XML representations of the objects, and for 
decompiling XML representations of (Java) objects ioto (Java) objects. Hie JVM may supply an Applications 
Programming Interfece (API) to the compilation/decompilation extensions. The client 1500 and service 1502 may 
be executing within JVMs. The JVMs may be on the same device or on diJBferent devices. 

In both Figure 35a and Figure 35b, the JVM XML compiler/decompiler API 1530 may accept a Java 
object 1510 as input, and output an XML representation of the object 1510 and all its referenced objects (the object 
gra^jh of object 1510) in an XML data stream 1514. In addition, the JVM XML compiler/decompiler API 1530 
may accept an XML data stream 1522, which includes an XML representation of object 1520 and all its referenced 
objects (the object graph of object 1520), and output Java object 1520 (and all the objects in its object ^ph). 

Figure 35a illustrates one embodiment where, when sending Java object 1510, the client calls the JVM 
XML compiler/decompiler API 1530. The client 1510 passes Java object 1510 to the API 1530, which compiles the 
object to produce its XML representation, stores the XML representation in XML data stream 1514, and ou^uts 
XML data stream 1514. The cUent may then pass XML data stream 1514 to gate 1504. Gate 1504 may then 
package the XML data stream 1514 in an XML message 1516 and send message 1516 to service 1502. 

Upon receiving XML message 1524 from service 1502, gate 1522 may extract XML data stream 1522 
from message 1524 and pass data stream 1522 to client 1500. Client 1500 may then call the JVM XML 
compiler/decompOer API 1530, passmg API 1530 the XML data stream 1522. The API 1530 may then decompUe 
the XML data stream 1522 to produce Java object 1520 and other objects in its object graph, returning the objects to 
client 1500. 

Figure 35b illustrates another embodunent where, when sending Java object 1510, the JVM XML 
compiler/decompUer API 1530 is called by the gate. The cUent 1510 passes Java object 1510 to gate 1504. Gate 
1504 then passes object 15 10 to API 1530, which compiles the object to produce its XML representation, stores the 
XML representation in XML data stream 1514, and outputs XML data stream 1514. Gate 1504 may then package 
theXMLdatastream 1514 inanXMLmessage l516andsendmessage 1516toservice 1502. 

Upon receiving XML message 1524 from service 1502, gate 1522 may extract XML data stream 1522 
from message 1524 and pass data stream 1522 to tiie JVM XML compiler/decompiler API 1530. The API 1530 
may then decompile the XML data stream 1522 to produce Java object 1520 and other objects in its object gr^h. 
The gate may then send Java object 1520 and the other objects to client 1500. 
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In one embodnnent, te JVM XML compiler and decompiler may be in^plemented as integ^ted fimctions 
of the JVM In another embodiment, fte XML con^,iler and decornpiler may be embodi^ 
invocations in standard extensions to the IVM; thus, the core IVM does not have to be modified. The JVM may 
supply the JVM XML compiler/decompiler API 1530 to processes (cUents and/or services) executmg witbm Ihe 
i jVMtoallowtheprocessestoaccesstheJavaobjectcompilation/decornpilationfimctionalityp^^^^ 
M one embodimenUor a proce«> to utilize the object compilation/decompilation, the JVM 
is executing must have the JVM XML compiler/decompiler fonctionality and API1530. 

Methods using reflection and serialization to transform and send objects are typically implemented m 
applications separate from the JVM. Ibe application must repeatedly access the JVM to pick ape« an object one 
0 field at a time as fte transitive closure of the object is dynanricaUy analyzed. Tte tends to be a slow and 
cumbeisome process, ^vbile also reciuiring large amounts of appUcation and JVM code. 

Implementing the Java object compilation/decompilation toctionaUty vri^ 

because the JVM already understands the concept o£ and contents o^ an object graph. Thus, the 
compilation/decompflation fimctions may leve«ge the lorowledge (and reuse code) of 4^ 
15 graph to produce the XML representation, and in parsing the XML representation to produce the object gr^h. 
Tl^us ftecompUation/decompilationfunctionsmaynothavetodupHcatefimctionahty 

as ^ object sending methods ^ing reflection and serialization. This may aUow the code foo^ of the 
compilation/decompilation functions to be smaUer than that of object sending medrods using reflecttoa and 
serialization. Also, an object may be complied or decompiled by a single call to the JVM XML 

20 compiler/decompaer API. , 

in addition, integrating the compilation/decompilation of objects with the JVM may aUow the compUatron 
and decompilation of objects to be performed faster than methods using reflection and ^.rialization because, m the 
object traversal model implemented with reflection and serialization, the code outside the JVM does not know the 
structure or graph of the Java object, and thus must traverse the object graph, pulling it apart, and ultimately must 
25 repeatedlycallupontheJVMtodothecompilation(andthereverseprocessfordecompilation).Th^ 

be slowed by the necessity of making repeated calls to the JVM, outside lie code. Having the compilation and 
decompilation toctionality integrated wiflrtheJVM-descrtT>edhereu. avoids h 

codeoutsidetheJVMtotheJVM.Inoneembodiment.anobjectn«ybecompliedordecompiledbyasmgle^^ 

tbie JVM XML compiler/decompiler APL 

to one embodiment, the compilation/decompilation fimctionality may be implemented as a service m the 
distributed computing enviromnent ■n.e service may publish a service advertisement in a space. Aprocessmthe 
distributed computing environment may use a search or discovery service to locate the compilafion/decompdatron 
service The process (a client of the service) may then use the service by passing Java objects to be compiled mto 
XML representations and/or XML representations to be decompiled into Java ejects to fee 

Java objects may include code (the object's methods) and data. An object's code may be non-transient; the 
code doesnot change oncetheobjectis created. An object's data, however, may be tnmsient Two objects created 
from iie same Java class may include identical code, but the data in the two objects may be different hi one 
embodiment, the compilation function may compile a Java object's data mto an XML representation of the object, 
but may not include the object's actual code in the XML represenUition. In orie pediment, informatm about the 
object may be incMed in the compiledXML representation to indicate to the receiver how to recreate the 
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the object me XML representation may then be stored in an XML data stream and sent (e.g. in a message) to a 
reviving process (client or service). ^ receiving process may then pa. the XML data stream to the 
decompaation fimction. TTxe decompilation function may then decompile the XML data stream to produce the Java 
object including its data. In one embodiment, the code for the object may be reproduced by the decompilatm 
function using infomation about the object inctaded in the XML representation, ^ 

statically defined and the JVM receiving the object may be able to reproduce the code (if necessary) usmg its 
knowledge of the object 

In one embodiment, the XML representation of an object produced by the compilation fimcti^^^ 

include the Java object's data and infonnation about the Java object The information may inctade class information 
fortheJavaobject An object signatme may be included in the infonnation and may be used to identify the object's ■ 
class etc Hie decompUation function may iecn«.te the code for the Java object using the information about the 
Java object and may decompile flie data from the XML data stream into the Java object Thus, a complete object 
including its code and data may be i^roduced on the JVM executing the receiving client or service fi-om the 
decompiled data and the information describing the object In one embodiment, the infomuition descnbmg the 
object may be stored in one or more XML tags, hi one embodhnent, the client or service «ceiving the XML data 
stream may include an XML schema that descriT^ the object, and the XML schemam^beused to r^^ 

Java object from the decon^iled data and fix,m the infonnation about the Java object The deco^^^^^^ 
may proceed recursively through the object graph, reconstructing the objects referenced by the object by 
decompiling the referenced objects' data from the XML data stream and recreating the referenced objects' code 
20 from information about the referenced objects in the XML data stream. 

In one embodiment, the XML representation of the object produced by the compilation fimcdon may 
include the object's data and mformation that identifies the code of an object In one embodiment, the information 
identifyingtheeodeoflheobjectmaybestoredhioneormoreXMLtagsintheXMLdatastream. When received. 

the decompilation function may rebate the code for the Java object using the infonnation about the code from the 
25 XML data sfream and decompile the data for the object from the XML data stream. Thus, a complete object 
including its code and data may be reproduced on the JVM executing the receiving cUent or service from the 
decompiled data and tiie infonnation describing the code of the object 

Several scenarios of usmg XML representations of objects to transfer objects between entities (typically 
clients and services) in a distributed computing environment are included for cterificatioi. These scenarios are 

30 exemplary and are not mtended to be limiting. . \rK/n 
In a fin* scenario, a service may use the XML compiler/decompfler to compile a Java object mto an XML 

n^presentation of the object and send the XML representation to a client THe cUent may the use the XML 
compiler/decompiler to decompile the XML representation and perfonn operations on the data wilhm the object. 
andktermayusetheXMLcompiler/decompilertocompaetheobjectintoanXMLrepresentationofthe^^^^^ 

35 return the XML representation offlie object to the service. 

In a second scenario, a service may use the XML compiler/decompUer to compile a Java object into an 
XML representation ofthe object and send the XML representation to a client THe client may ten send the XML 
representation to another service, which may use the XML compDer/decompiler to decompile the XML 
representation to reproduce the object, peribmi operations on the object at the request of the cHent (possibly 
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„.odifying Ihe data).>se the XML conq>aer/deoompacr to xeconipile tbe modified object into its XML 
representation, and send the XML representation of the object to tbe client 

In a third scenario, a service may use the XML compiler/decompiler to compile a lava object mto an XML 
representation of the object and send the XML representation to an object repository or store space. The service 
5 ^nay then send a message to a cUent Morming the client of the location of the XML representation. The message 

„,ay include a Universal Resomx=e Identifier (URI) for the XML representation. Th. cUent may then retneve the 
XMLrepresentationof.heobjectfromthestorespace,andmayusetheXMLcompiler/decompi^^ 
repres^tationtoreproducetheobject Alternatively, the client may send the location of the XML representation of 
the object to another service, along with a request for operations to be performed on the object The other serv.ce 
,0 m^thenretrievetheXMLrepresentation&omthestorespacc,usethcXMLcompil^^^^^ 

XML representation to reproduce the ol^ ect. and perform the reque^ 

to a fourth scenario, a process (could be a cUent or service) may locate an objectrepository ^^^^^^ 

in the distributed computing environment by searching for and finding a service advertisement for the store space. 
■n.e process may. during execution, create or obtain a plurality of Java objects. Tl»e process may use fte XNO, 
15 compiler/decompUer to compDe one or more of the objects into XML representations of the objects, and may ^d, 
as a cUent of the store space service, the XML repi^sentations of the objects to the store space to be stored for 
possible later access, or for access by other processes. 

Security issues in the Decompilation of XML Representations of Objects 

spaces asdescnT,edherein.mayserveasafilesysteminthedis.riWcomputingenvironment Secun^ 

20 maybeprcvidedforfilesinthe^stemintheformofaccessrights. Access rights may be checked each tm.e a file . 
accessed (opened, read, or written to), n^us, a method for providing file access security in Are distribute . 
computing enviromnent may be desirable, m method may also be applied to the XML representations of Java 
objects that may be stored in spaces and transmined between cUents and services in the ^^^^^^^ 

environment , ^ -u 

25 m one embodiment, a user of a client on a device in the distributed computing env^omnent may be 

identified and authenticated when fi«t Accessing the client to one embodiment, the user may supply a phys.cal 
identification such as a smart <^d for identification and aufcorization. to another embodiment, a chaUenge- 
«sponse mechanism (such as user ID and password) may be used for identification and authorization. Yet another 
embodiment may use electronic identification such as a digital signature for identification and 

30 other method of identification and authorization may be used. .. 

Once identified and authorized, the user may then perfonn various operations on the client, mcludmg 

accessing one or more services m the distributed computing environment During these operations, as described 
above oneorm<*eobjectsmaybecreated(locally)oracquiredftomelsewhe,e(e.g.ftoms^^^ 
object may be modified and may be compUed into XML representations of the objects and 
35 client or sent to a space service for (transitive or persistent) store. Some of the pb]^ may be received fiom 
services (store services or other services) in the form of XML representations of the objects, which may be 
decompiled by the XML compiler/decompiler to recreate the objects on the client 

to one embodiment during the decompilation of the XML representation of objects, each XML message 

n^y be checked to verify that the user has access rights to the object If the user does not have the proper access 
rights the XML compiler/decompiler may BOt decompile the object for the user, to one embodiment a security 
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exception may be thrown by the XML compUer/decompiler. In one embodiment, the nser may be infonned of the 

access violation. 

Access right information, such as the creator and access levels aUowed (creator-only access, read only, 
leadMrite, delete, copy, etc.) for the object may be embedded in the XML message{s) containing the XML 
5 representation of the object Access authori2ation may be determined during (he identification and authorization of 
the user. For example, the object may aUow "read only" access for most users, and "readMrite" access for the 
creator of the object If the user tries to access an object using readAvrite access rights, and the user did not create 
the object, the decompilation process may detect this as an access violation, and may disallow the access and notify 
flieuser. 

10 inoneembodiment,whenthenserisdoneusiDgtheclient,theuserinaylogofforotherwisesignaltbeuser 
is finished with the client (e.g. remove a smart card). Objects created on the client by decompilation may be 
automatically deleted >vhen the cUent detects that the user is finished. This may prohibit future users flom 
intentionally or accidentally accessing the user's objects. In one embodiment, all objects created by decompilation 
may be deleted upon detecting that the user is finished. In another embodiment, a method may be provided to store 

15 at least some of the objects created on the client persistently (e.g. with access rights mformation). so that the cMent 
may later access the objects, or provide aie objects to other users for access. 

In one embodiment, the user may have a "smart card" or otter physical device to gain access to the cUent 
The user may insert the smart card into flic client device to begm the session. When the cKent is finished, the cUent 
may remove the smart card. The client may detect the removal of the smart card, and thus detect that the client is 

20 finished, and may then proceed to delete objects created by decompilation of XML representations. 

XML-based object repositories 

In the distributed computing environment, processes (services and/or clients) may desire transient and/or 
persistent storage of objects such as XML schemas, service advertisements, results generated by services, XML 
representations of Java objects and/or objects implemented in other languages, etc. Existing object storage 
technologies tend to be language and/or operating system specific. These storage systems also tend to be too 
complicated to be used with small footprint systems such as embedded systems. 

JavaSpaces m Jini is an existing object repository mechanism. A JavaSpace may be only capable of storing 
Java objects and may be too large to be implemented in small devices with limited amounts of memory. Each object 
in a JavaSpace may be serialized as previously described, and thus has the same limitations as previously described 
for the reflection and serialization techniques: 

A store mechanism may be provided for the distributed computing enviromnent that may be heterogeneous 
(not language or operating system dependent), that may scale &om smaU to large devices, and that may provide 
transient or persistent storage of objects. In one embodiment, the store mechanism in the distributed computing 
enviromnent may be implemented as an hitemet Web page or set of pages defined in fte XML maibip language. 
XML provides a language- and platform-independent object representation format enabling Java and non-Java 
software to store and retrieve language-mdependent objects. Since the store mechanism is on the Web, devices of 
all types and sizes (small to large) may access the store mechanisms. Web browsers may be used to view the store 
mechanism implemented as Web pages. Web search engines may be used to search for contents in the store 
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mechanism implemented as Web pages. Memet administration mechanisms (exisfcg and to) 
may be used to administer tiie XML-based store mechanisms. 

In one embodiment, the store mechanisms may be used to store objects created, represented or 
encapsulated in XML. Examples of objects that may be stored m the store mechanisms may include, but are not 
limited to: XML schemas, XML representations of objects (for example, Java objects compiled into XML 
representations as described above), service advertisements, and service results (data) encapsulated in XML. to one 
embodiment, to prevent unauthorized access of an XML object, an authorization credential such as a digital 
signatureorcertificatemaybeinchidedwiththeXMLobject,andacUentwishingtoaccess&^ 
required to have the proper authorization credential to access the XML object In one embodunent, the store 
mechanism m^ be a space as described inihe Spaces section herem. 

Store mechanisms may be services in the distributed computing enviiomnenL A store mechanism 
implementedasaservicemaybereferredtoasa-storeservice''. A store service may publish an advertisement in a 
space The space itself is an example of a store service. Some store services may be transient For example, a 
space service that stores service advertisements may be a tr^ient store. Other store services may be pers«itent 
For example, a store service that stores results from services may be a persistent store. 

Figure 36 illustrates a client 1604 and a service A 1606 accessing store medmnisms 1600 and 1602 in the 
distn^uted computmg enviromnent acconling to one embodhnent Th^ 

is not intended to be limiting to thescope of this invention. In one embodiment, store mechanisms 1600 and 1602 
may each be an Intemet Web page or set of Web pages defined in XML and accessible by a Web browser and oa^^ 

totemet tools. Store mechanism 1600 is a transient store capable of storing objects implemented using XML. Store 
mechanism 1602 isapersistentstorealsocapableofstoring objects implementedusingXML. Service A 1606 may 
publish an XML service advertisement 1608 in transient store 1600. Persistent store may also publish an XML 
service advertisement m transient store 1600 (or on another transient store in the distributed computmg 
enviromnent). At some pomt, client 1604 may require ftnctionality provided by Service A 1606. Client 1604 may 
use a discovery and/or lookup service to locate service advertisement 1608. CUent 1604 may then construct a 
message gate, as described herem. and begin communications with Service A 1606. Client 1604 may send one or 
more XML request messages to Service A 1606. Service A 1606 may perform one or more functions m response to 
the one or more request messages, one or more ofthe functions perfom^ed by ServiceA1606 may prxKluce^ 

to be provided to client 1604, 
) For transient restdts 1610, service A 1606 may encapsulate the resuhs man XML advertisement 1^^^^ 

publish the advertisement 1612 in transient store 1600 (or on another transient store m the distributed computing 
enviromnent). Service A 1606 may then notify client 1604 that the results 1610 are stored in advertisement 1612 on 
transientstorel600,orcUentl604maybenotifiedbyotiiermed>anismsasdescn^^ CUent 1604 may then 

retrieve transient results 1610 from advertisement 1612. TTxe advertisement 1612 may mclude an XML schema 
5 descn^ingtheformatting, contents, type,etc.ofti.etransientresnlts 161^^ Tte results may be encapsulated m 
XML. For example, XML tags may be used to describe portions of the data: 

<XMLtagl> <datal> 
<XMLtag2> <data2> 
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For persistent results 1618, Service A 1606 may use a service or other mechanism as described herein to 
locate XML service advertisement 1616 for persistent store 1602, and thus locate persistent store 1602 for storing 
persistent results. Alternatively, client 1604 may have previously located persistent store 1602 by locating its 
service advertisement 1616, and then may send a Umversai Resource Identifier (URT) for a storage location for 
persistent results 1 6 1 8 to Service A in an XML message. In one embodiment, persistent results 1618 may be stored 
in an Internet Web page or set of Web pages defined in XML and accessible by a Web browser. Service A 1606 
may then store persistent results 1618 in persistent store 1602. Service A 1606 may then publish an XML 
advertisement 1616 for the persistent results 1618 in transient store 1600 (or on another transient store in the 
distributed computing envkonment) and return the location of the advertisement 1616 to client 1604. The 
advertisement 1616 may include an XML schema describmg the formatting, contents, type, etc. of the persistent 
i^ults 1618. The results may be encapsulated in XML as previously described The advertisement may also 
mclude die URI of the persistent results 1618. The cHent 1604 may then retrieve the advertisemOTt 1616 and use it 
to locate and retrieve persistent results 1618. Alternatively, Service A 1606 may not publish an advertisement for 
persistent results 1618, but instead may return a URI for the persistent results 1618 to client 1604 so client 1604 
may access the results without looking up an advertisement Note m some embodiments, the various advertisements 
shown in transient store 1600 m^ each be stored in different transient stores or spaces. 

Thus, store mechanisms may be implemented as XML-based Internet Web pages in the distributed 
computing environment These store mechanisms may be implemented on a variety of devices in the environment, 
and may provide service advertisements to allow chents (which may be other services) to locate and use the store 
mechanisms. Existing and future Web and XML tools may be used to manage the store mechanisms. The store 
mechanisms may store objects of various types implemented or encapsulated in XML. Clients on devices of 
substantially any size, fi-om small footprint devices to supercomputers, may access the store mechanisms to store and 
retrieve the various objects on the hitemet The clients may be Java or non-Java ^pUcations, as XML provides a 
language-independent storage format The transient or persistent object repositories may provide for a file system in 
tiie distributed computing envhomnent and may include access checks and other security mechanism as described 
herein. 

Dynamically Convertmg a Java Object into an XML Document 

In one embodiment, the distributed computing envhonment may provide a mechanism to convert and 
represent an object class instance into an XML document In order to send representation of a class instance to 
another service, the object may be converted and represented as an XML document In one embodiment, when 
receiving an XML document, a program may instantiate a class instance corresponding to the object represented by 
the document In one embodiment, the objects may be Java objects, and the program may be a Java program. 

In one embodiment, an intermediary format may be used to represent an XML document and may be 
dynamicaUy processed to generate a class instance that represents the XML document T^^ 
instance variables and "set and get" methods to access the instance variables. A corresponding XML document may 
be defined as a set of tags, with one tag for each mstance variable. When the document is parsed, a hashable 
representation may be constructed where the hash key may mclude die mstance variable name and the vahie may 
include the mstanc& variable value. If there.are multiple occurrences of a complex instance variable, an enumeration 
value may be stored m a hash table. In one embodiment, the process may be linnted to only one level of complex 
types for the instance variables, and the elements may be homogeneous. 
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In one embodiment, a protected instance variable may be added to &e class definition that may include the 
name of the coiresponding class. The XML document representation may use the class name as the document type. 
Having the class name embedded in the document may allow dynamic instantiation of the right class instance when 

the object is reconstructed. 

5 In one embodiment, upon receiving a document, a class instance generator method may be used to extract 

the class and to parse the document to generate the intermediary hash table representation. The generator 
method may instantiate a new class instance and may use the set methods to initialize the instance object from the 
hash table values. In one embodiment, smce the class type is defined and the hash table is generic, this process may 
be performed for any class that matches the above class definition. 

10 In one embodiment, the reverse process may also be performed where a class mstance may be processed 

into the totermediary hash table representation and a generator method may be used to produce an XML document 
flx)m 4e hash table representation. This process may also be made generic so to itm^ be performed for any XML 

document that matches the above specification. 

This method is not mtended to be limited to Java Class objects, and may be appUed to other computer- 
15 based objects, including class object instances of other programming languages, hi addition, the method is not 
mtended to be Umited to XML representations of object instances; other representation fonnats includmg other data 
repnsentation languages (such as HTML) may be substituted for XML. 

XML-Based Process Migration 
20 The distributed computing environment may enable the distribution and management of distibuted 

appUcations. For example, the distributed computmg environment m!^ mchde mobile cUents that are dockable 
with stations that provide monitors, printers, keyboards, and various other input/output devices that are typically not 
provided on mobile devices such as PDAs, cell phones, etc. These mobile cUents may run one or more appUcations. 
and may migrate from one station to another m the distributed computing enviromnent Thus, one embodiment of 
25 the distributed computing enviromnent may provide a method for migrating an executing appKcation (process) wiUi 
its entire current state from a mobile cUent on one node to the same mobile cHent or another mobile cUent at another 
node withm the distributed computing environment. 

In one embodunent, an XML representation of the state of a process executing on a cUent or service may be 
created. In one embodhnent. the XML representation of flie state of the procKS may include a computation state of 
30 the device and/or virtual machme on which the process is executing, wherein the computation state of the device 
and/or virhial machme comprises information about the execution state of the process on the device and/or virtual 
machine. A process state may mchide, but is not limited to: threads, all objects referenced by the threads, transient 
variables created during the execution of the process, objects and then: data, etc. to one embodunent. data 
describmg one or more leases representing grants of access to external services, obtained from spaces by the 
35 process, wherem the one or more external services are external to the device and/or virtual machme on which the 
process is executing, may also be represented in XML and stored with tiie process state. Leases are described in 
more detail in the Leases section of fliis document. 

Using XML and the messagtog system as described herein, an XML representation of the state of a process 
may be moved from node to node withm the distributed computing enviromnent. e.g. from node to node on the 
40 totemet The XML representation ofthe state of a process may also be ston^ as an XML object in an Xl^ased 
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store mechanism as described above, and later retrieved from the store mechanism to resume fte process execution 
on the same node or on a different node u» the distributed computing environment In one embodiment, the XNIL 
Object compilation/decompUation process as described herein may be used in creating (compiling) an XML 
representation of the state of a process and in regenerating the state of the process by decompiling the XML 

representation of the state of the process. 

Using tWs mechanism, an XML representation of the state of a process may be stored in an XML-based 

store mechanism, such as a space, from an initial node. Subsequentiy, anotiier node rnay locate the stored state of 
the process, download the state of the process, and resume the process from the downloaded stored state at the point 
at which it was executing when the state was stored. Since the process state is stored in an XML format, the tools 
and search fecilities described herein to store, locate and retrieve XML objects in XML-based store mechanisms 
may be used to enable the migration of the process. An advertisement ofthe stored XML representation of the state 
of the process may be published to allow a cKent resuming the process execution on the same node or another node 

to locate and access flie stored sate. 

The XML representation of tiie state of a process may be stored to an XML-based persistent store 
mechanism, and thus may provide a persistent snapshot of the process. TTiis may be used as a method to resume 
process execution on a node after the interruption of the process on the node, fer example, due to the intentional or 
unintentional shutdown of the node. An advertisement of the stored state of tiie process may be published to aUow 
cHents to locate the stored state in the distributed computing environmenL In one embodiment, to prevent 
unauthorized access of an XML representation of the stored state of aprocess, an autiiorization credential such as a 
digital signature or certificate may be included with tiie stored state, and a cUent wishmg to resume a process from 
the stored state m^ be required to have flje proper authorization credential to access tiie stored state. 

Figure 37 illustrates process migration usmg an XML representation of the state of a process according to 
one embodiment Process A 1636a may be executing on node 1630. Process A 1636a may be a cUent or service. 
At some point during flie execution of Process A 1636a, tiie state of execution of Process A 1636a may be captured 
and stored in an XML-encapsulated state of Process A 1638. Hie execution of Process A 1636a on node 1630 may 
tiien be stopped. Later, node 1632 may locate tiie XML-encapsulated state of Process A 1638 and use it to resume 
Process A 1636b on ttie node 1632. Resuming Process A may include using the stored state 1638 to resume tioead 
execution, recalculate transient variables, re-establish leased resources, and perform any otiier functions necessary to 
resume execution as recorded in tiie stored XML state of flie process 1638. 

The following is an example of using XML-based process migration in tiie distributed computing 
ehviromnent, and is not intended to be limiting. A mobfle client device may be comiected to node 1630 and 
executing Process A 1636a. TTie user of tiie mobUe cUent device may desire to stop execution of Process A 1636a 
on node 1630, and to resume execution at a later time at anotiier (or tiie same) node. In one embodhnent. tiie user 
may be prompted wifli a query to determine if tiie user wishes to store flie state of Process A 1636a and resmne 
execution later. If tiie user repUes in flie affirmative, tiie XML^capsuIated state of tiie process may be captnred 
and stored in persistent store 1634. Later, flie user may connect tiie mobUe computing device at node 1632. In one 
embodiment, flie user may flien execute process 1636b and select a "Resume from Stored State" option. Hienbde 
• 1632 may tiien search for and locate tiie XML-ericapsulated state of Process A 1638, download it, and use it to 
resume Process A 1636b. Alternatively, tiie process may itself know that it was "suspended" on anotiier node, and 
0 may resume from the stored state witiiout user input 
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Applications 

Technologies exist that allow a user to access network data from remote locations, making the remote data 
appear as local data to the user, provided the user has access to a browser. However, such technologies do not 
provide an automatic u^astructoe to query networks near a client device's location. A mechanism for discovermg 
information about networks and services near a client device be desirable. For example, such a mechanism 
may be used to locate information about restaurants, weather, maps, traffic, movie mformation, etc withm a certain 
distance (radius) of the cUent device, and to display desired information on the client device. An example of using 
this mechanism may be a cell phone that can be used to automatically locate services m a local environment, for 
example, in a movie theater to display the titles and show thnes of current features in the movie theater or in a 
restaurant to view menu selections and prices. In Ae distributed conq)Uting enwonment as described herem, such a 
mechanism may be used to discover spaces including local infonnation and/or services fHTOxhnate to tiie cUent 
device. The mechanism may also be applied in other distributed computing environments, for example, the Jini 
system from Sun Microsystems, Inc. 

hi one embodhnent, a mobile client device may include Global Positioning System (GPS) capabiUty and 
wireless connection technology. Local distributed computing networks may be provided For example, a city may 
provide a citywide distributed computing environment Another example may be a shoppmg mall with a local 
distributed computing environment. A local distributed computing network m^ include a discovery mechanism to 
allow client devices to connect to the distributed computing environment and to discover services and data in the 
local enviromnent For example, one or more devices in the environment may hiclude wireless connection 
technology to aUow mobile client devices to connect to the network and to access the discovery mechanism via the 
XML messaging system as described previously. A local distributed computing environment may include one or 
more spaces with advertisements for services and/or data to be made available to mobOe cUents. For example, a 
eitywide distributed computing environment may mclude spaces that represent entities such as malls, movie tiieaters, 
local news, local weather, traffic, etc. A space may include individual service and/or data advertisements for 
accessmg services of and mformation about tiie entity the space represents. The discovery mechanism may mclude 
a GPS location or locations of the local distributed computmg environment, entities represented by space services 
withm the environment, and/or the various services advertised in tiie spaces in the envir^^^ 

In one embodhnent, wired connections may be provided to a local distributed computing network, to this 
environment, a user witii a mobile client device may ^ug in" dhectly to the network using a wired connection 
"dockmg station". Examples of wired connections include, but are not limited to: Universal Serial Bus (USB), 
FireWire, and twisted-pair hitemet hi one embodiment, a docking station may also provide input/output 
capabihties such as a keyboard, mouse, and display for tiiemobUe client device, hi this embodiment, the location of 
the mobOe client device may be provided to the lookup or discovery mechanism by tiie docking station. 

In one embodhnent, a mobile client device may connect to a distributed computmg network. As the user of 
tiie mobile cheat device navigates withm wireless communications range of tiie distributed computing network, tiie 
mobile chent device may constantiy, or at various intervals, provide a location vector as mput to tiie local lookup or 
discovery mechanism. The mobile chent device may obtain the location vector from a GPS syst^ buih into or 
associated wrtii tiie mobOe chent In one embodiment, tiie chent may send its location mformation (e,g. via XML 
messaging) to a local service discovery mechanism, such as one of tiie space location mechanisms described herem. 
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For example, the cUent may run the space discovery protocol specilymg discovery for spaces offering services 

within a certain range of the cUenfs location, or the client may instantiate a space search service to search for spaces 

advertising services provided for the client's vicinity. 

As the mobile Ghent device moves into a specified range of a space within the distributed compiit^^ 

5 environment, the services and/or data stored in the space may be made avaUable to the mobile client device. In 
embodiments where the cUent device regularly provides its location to a discovery mechanism, local services and/or 
data may automatically be made available to the cUent's user. In one embodiment, the user of the mobile cUent 
device may determine the specified range of a space. For example, flie user may choose to display aU restaurants 
within one mUe of a cunent location. Alternatively, the range may be specified in the configuration of the local 

10 distributed computing netwodc For example, a cilywide dktributed computing network may be configured to 
provide its services to all users within three miles of the city limits. In one embodiment, visual indicators, for 
example icons, representing the various services and/or data offered by the space may be displayed on the mobile 
client device. The cUent may then access one or more of the displayed services and/or data. In one embodiment, 
information from two or more spaces may be displayed simultaneously on the mobile client device. In one 

15 embodiment, the user may select what services and/or data are to be detected. For example, in a shopping mall, a 
user with a mobile client device may choose to display all shoe stores in flie malL 

In one embodiment, executable code and/or data used in the execution of the code may be downloaded to 

the mobile client device to allow the user to execute an application provided by a service in the space. For example, 
moviegoers with mobile cUent devices may download interactive movie reviews from services in a space for the 
20 movie theater, and may thus perforai real-time feedback about the movie they are watching. In one embodiment, an 
XML object compilatlon/decompilation mechanism as described elsewhere herem may be used to compile the code 
and/or data to produce XML representations of the code and/or data, and to decompile the XML representations to 
reproduce the code and/or data on the mobile client device. In one embodiment, an executable version of a process 
may previously exist on the mobUe client device, and a stored state of the process may be downloaded to the mobile 
25 client device to aUow the user to execute the process using the stored state. In one embodiment, an executable 
version of a process may previously exist on the mobile cUent device, and data for the process may be downloaded 
to the mobile cUent device. For example, data may be downloaded for viewing with a viewerpmgram onthe mobile 
client device. In one embodiment, an executable version of a process, including the code and data for executing the 
process, may be downloaded for execution on the mobile client device. In one embodiment, the service may execute 
30 the appUcation remotely on behalf of the mobile cUent device, and the service and client may pass to each other 
XML messages including data and optionally XML schemas describing the data. In one embodiment, some code 
may be executed on ttie service and some on the client For example, the service may execute code to perform 
operations on a set of data such as nmnerical calculations. The mobile client device may execute code that ms«^ 
display portions of the data passed to the cUent from the service in XML messages and aUow the user of the mobile 
35 client device to enter and/or select data and send the data to the service for perfoimmg one or more operations on 
the data. 

In one embodiment, a mobfle cUent device may be connected tn two or more services in the distributed 
computing network simultaneously. The services may be used independently or in conjmiction for performing a 
series of tasks. For example, one service may be iised by a remote client device to locate and/or perioral operations 
40 on a set of data, and a second service may be used to print the set of data. 
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Figure 38 illustrates a mobile client device accessing spaces in a local distributed computing network, 
according to one embodiment. A user of QPS-enabled mobUe computing device 1700 may move into proximity of a 
local distributed computing environment TTie mobile client device 1700 may provide its location provided by GPS 
1702 to one or more discovery mechanisms 1706 in the local distributed computing network. Hie discoveiy 
mechanism 1706 may use the provided GPS location of the mobile client device and predetermined locations of 
spaces within the environment to detemme when the user moves within a specified range of one or more spaces or a 
vicinity served by one or more spaces within the environment For eiample, discoveiy mechanism 1706 may 
determine that mobile client device 1700 has moved within range of space 1704. Discovery mechanism 1706 may 
then provide one or more advertisements 1710 from space 1704 to the mobUe client device 1700. Alternatively, 
discovery mechanism 1706 may provide a Univei^ Resource Identifier CUKJ) for space 1704. or for one or more 
advertisements in space 1704, to mobUe client device 1700. Icons representing the various services advertised by 
service advertisements 1708 and/or data represented by content advertisements 1710 may then be displayed on 
mobile client device 1700. Tte user may then select one or more of the advertised services and/or data for 
execution and/or display on Ihc mobile eUent device. The mobile computing device 1700 may establish a wheless ' 
comiection with the device offering the service and communicate with the device to execute the service usmg the 
XML-based messaging system as previously described herein. AKernatively, the user of the mobfle computing 
device 1700 may comiect Ae device at a docking station. Tie location of Ihe docking station may have been 
discovered by the user using the lookup or discovery mechanism 1706. and spaces containing advertisements for flie 
docking stations to discover the location and availabiUfy of docking stations withm a specified range of tiie user. 

Discoveiy mechanism 1706 may also detect when mobile client device 1700 moves into a selected range of 
space 1714. TTie various service advertisements 1718 and content advertisements 1720 may then be made avaUable 
to the user of the mobile cUent device 1700. When the mobile client device moves out of the specified range of one 
of the spaces, flie advertisements offered by tiiat space may be removed from tiie mobile cUent device 1700's 
display. 

In one embodiment, advertisements on a space may include location information for the services or data 
that they provide. TTius. discovery mechanism 1706 may determine when mobile client device 1700 moves within a 
specified range of a particular service advertised on space 1718. and may provide (or remove) the service 
advertisement based upon tiie location of the mobile cUent device 1700. 

Computing devices are shrinkmg whfle at the same time gaining power and fimctionalhy. Storage devices. 
CPUs. RAM, I/O ASICS, power supplies, etc. have been reduced in size to where small, mobile cUent devices may 
include Wh of the fimctionality of a full-sized personal computer. However, some components of a computer 
system are not easily shrinkable because of the human fector and other fectors. IHese components include, but a« 
not limited to: keyboards, monitors, scanners, and printers. Ihe limits on reducmg the size of some components 
may prevent mobile client devices from truly assuming the role of personal computers. 

In one embodiment, docking stations may be provided that allow users with mobile cKent devices to 
comiect to and use components that are not available onlhe mobfle cUent device because of human or other fectors. 
For example, docking stations may be provided in public places such as airports or Kbraries. Hie docking stations 
may provide monitors, keyboards, printers or other devices for users with mobile client devices. In one 
embodiment, the docking stations maynot My flmction without help fiomareal computing device such asamob^ 
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client device connected by a user. The docking station may provide services such as various input/output functions 
to the client using the computing power of the mobile client device. 

A docking station may provide one or more connection options to a mobile client device. The connection 
options may include wireless connections and wired connections. Examples of wireless connections include, but are 
5 not limited to: infrared such as IrDA and wireless network connections similar to those provided by a network 
interface card (NIC) in a notebook computer. Examples of wired connections include, but are not limited to: USB, 
FireWire, and twisted-pair Ethernet 

A mobile client device may discover the location of docking stations using a method substantially similar to 
that described above for mobile client devices. The location of one or more dockmg stations m a local distributed 
10 computing network may be discovered using a discoveiy mechanism to discover spaces with advertisements for 
docking stations. The mobile client device may provide a location to the discoveiy mechanism. In one 
embodiment, the discoveiy mechanism or a lookup mechanism may return Ae location of one or more docking 
stations closest to the location of the mobOe client device. Alternatively, the discoveiy mechanism or lookup 
mechanism may return a URI of the space containing the advertisements for the docking stations, and the mobile 
15 client device may then connect with the space to provide the location of the one or more docking stations near the 
device. In one embodiment, the mobile client device may supply mforaiation to tibe lookop or discovery mechanism 
to specify requirements such as monitor resolution, screen size, graphics capabilities, available devices such as 
printers and scanners, etc. In one embodiment, information about the one or more docking stations may be supphed 
to the user on the mobile client device including availability (is another user using the docking station), components 
20 and capabilities of the various docking stations. 

When a user approaches a docking station, a clauning protocol may be initiated. When the docking station 
accepts the claim, secure mput and output connections may be established between the mobile client device and the 
docking station. Alternatively, the user may select the docking station from one or more docking stations discovered 
using the lookup or discovery mechanism displayed on the mobile client device. When the user selects the docking 
25 station, the claiming protocol may be initiated to give the user secure, exclusive connection to the docking station 
for the duration of the claim. A docking station release method may also be provided to allow the user to terminate 
the session on the docking station and release the docking station for use by other users. In one embodiment, the 
claiming protocol may be a lease on the docking station service as described previously herein. 

Figure 39a illustrates a user of a mobile device discovering the location of dockmg stations accordmg to 
30 one embodiment Mobile client device 1750 may connect with discovery mechanism 1756. Mobile client device 
1750 may provide a location obtamed usmg GPS 1752 to discoveiy mechanism 1756. Mobile cli^t device 1750 
raay also provide docking station requirements to discovery mechanism 1756. Discovery mechanism 1756 may 
search one or more spaces 1754 for advertisements for docking stations 1758 tiiat meet the requirements of mobile 
client device 1750. In one embodiment, a lookup or discoveiy mechanism may locate one or more docldng stations 
35 within a specified range of mobile device 1750 by comparing location information stored in advertisements 1758 
with the supplied location of mobile device 1750. Discovery mechanism 1756 may then provide the location of one 
or more docking stations within a specified range of mobile client device 1750. Altematively, discoveiy mechanism 
1756 may locate a nearest docking station to mobile client device 1750 and provide the location to mobile client 
device 1750. 
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Figure 39b illustrates a mobile client device 1750 coimecting to a docking station 1760, according to one 
embodiment In one embodiment, the user may move mobile client device 1750 into wireless range of docking 
station 1760 and make a wireless connection to the docking station 1760. In another embodiment, the user may 
establish a wired connection to docking station 1760 by connecting one or more cables between docking station 
5 1760 and mobile client device 1750* In one embodiment, the iiser of the mobile client device 1750 may establish a 
claim to the docking station 1760. The claim may establish secure, exclusive rights to the docking station for the 
duration of the connection. In one embodiment, the cljum mechanism may be a lease mechanism for a resource (the 
docking station) as described previously herem. In one embodiment, a user may be billed for use of the docking 
station. For example, the user may supply a credit card number as part of the process of clahning a docking station. 
10 Refer to the description of bill gates in the Message Gates section herein. Once connected, the user may use the 
various fecilities provided by the docking station 1760 such as keyboard, monitor, printer, etc. Docking station 
1760 may also include a connection to a local distributed computing network and thus may provide the user of the 
mobile client device 1750 connected to the docking station 1760 with discovery services for locating service and 
content advertisements on other devices within the network, allowing the user to locate and use various services and 
15 content m die distributed computing environment as described previously herein. 

When finished, the user may disconnect the mobile cUent device 1750 from the docking station 1760. In 
one embodiment, a docking station release mechanism may automatically be initiated when the mobile cHent device 
1750 is disconnected from the dockmg station 1750. The release mechanism may clear any claim on the docking 
station 1760 established by the user of the mobile client device 1750. In one embodiment, the release mechanism 
20 may notify the discovery mechanism 1756 and/or docking station advertisement 1758 that the docking station is 
available. 

In one embodiment, a user may connect a mobile client device to a docking station without using the 
discovery mechanism. For example, a user hi an airport may visually detect a deciding station and connect a mobile 
client device to it. Another example may be a library providing a docking station room with a plurality of dockmg 
25 stations for use, where users may access any of the docking stations that are available. 

Small Footprint and/or Embedded Devices 

Simple embedded or small footprint devices may have limited amounts of memory for storing and 
executing program instructions. A simple embedded device may need to understand a lunited set of control mputs 

30 for mitiating functionality of the device and outputs for reporting the status of the device. An example of a simple 
embedded device is a '*smare' switch (such as a light switch) with embedded circuitry for controlling the switch and 
thus the device controlled by the switch- The smart switch may only need to understand two control requests 
(change the state of the device, request the state of the device) and to send one status message (the state of the 
device). The smart switch may manage the device to v^iiich it is connected by receiving its control requests from 

35 one or more control systems and reporting status messages to the one or more control systems. 

In one embodunent, the distributed computing environment may provide a framework (protocol) for 
including small devices that may not have the resource footprint (such as memory) necessary to implement the fiill 
protocol of the distributed computing environment In one embodiment, an agent may be provided as a bridge 
between die small device-capable protocol and the fiill protocol. Tlie agent may perform the full protocol discovery 

40 for the small device, so the device may not be required to implement the fiiU discovery protocol and service 
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activation. In one embodiment, the small device may only need to send service-specific messages. In one 
embodiment, these messages may be pre-cooked on the small device, so the small device may only have to send 
messages that are part of the service activation to the agent The agent may perform the service activation via the full 
protocol to the service and forward mcoming message from the device to the service, and/or may forward replies 
from the service to the client Thus, the agent may act as a service connector for tiie small client. 

In one embodiment of the distributed computing environment, an embedded device be configured to 
receive a specific set of control requests in the form of XML messages and to send a specific set of XML messages 
to make requests, report status, etc. In one embodiment, a control system may be configured to manage a variety of 
devices by sending XML request messages specific to each device or category of device that it controls and by 
receiving XML messages from the devices. In one embodiment, one or more XML schemas may be used to define 
an embedded device's specific set of XML messages; the schema may be used by tiie embedded device and/or the 
control system in sending and receiving XML messages. 

An embedded device may include a 'thm" implementation of the XML messaging system as previously 
described herem that supports the specific set of messages for ccntrollmg and monitoring the simple embedded 
device. The inqjlementation of the XML messaging system may be tailored for use with small footprint, simple 
embedded devices, and thus may fit in the Innited memory of the small footprint devices. In one embodiment, the 
XML messaging system may be hnplemented in a small footprint with a virtual machine tai^eted at smaU footprint 
embedded devices (e.g. KVM). A networking stack (to support the transport protocol for communications with one 
or more control systems) may be associated with the vntual machine and the XML messaging layer may "sit on top" 
of the networking stack. It is noted that this implementation of the messaging system may be used m odier devices 
than small footprint or embedded devices. 

In one embodiment, static or pre-generated messages may be used for requests from control systems to 
embedded devices. The static messages may be precompiled and stored in the embedded devices. An mcommg 
message may be compared with the stored static messages to find a match for the message and thus to perform the 
fimction requested by tiie message, th\is reducmg or eliminating the need for code to parse incoming messages. 
Outgomg messages may be read dkectly from the stored static messages, thus reducing or eliminating the need to 
dynamically compile outgoing messages. Thus, static messages may be used to reduce tiie code footprint of the 
messagmg layer in embedded systems. For example, static Java objects (Java op codes) may be used for request and 
status messages. 

Figure 40a filustrates an embodunent of embedded devices 1804a and 1804b controlled by a control system 
1800, accordmg to one embodhnent Control system 1800 may be networked with the devices 1804a and 1804b it 
controls in any of a variety of ways. The network 1810 may be wired (E&eraet, coaxial, twisted parr, power grid, 
etc.) and/or wfreless (IrDA, microwave, etc.). Ih one embodhnent, embedded devices 1804a and 1804b may include 
a thin in^lementation of the XML messaging system for communicating vwtfa control system 1800 over network 
1810. Control system 1800 may have an implementation of the XML messaging system for sendmg requests to and 
receivmg responses from embedded devices 1804a and 1804b. In one embodunent^ control system 1800 may 
mclude software and hardware configured to present an interfece to allow a user to display the status of and 
remotely control the embedded devices 1804a and 1804b. In one embodunent, control system 1800 may include 
software and/or hardware for automatic control of embedded devices 1804a and 1804b. 
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In one embodiment, embedded devices 1804a and 1804b may be part of another environment. Tte 
devices may not support lhe message passing model implemented by the distributed network en™^ For 

example, the devices may be nodes in a networked automation and control system such as a LonWorks network. 

Control system 1800 may include a control system hardware and/or soflwa,^ for controlling devices in the other 
5 environment. Control system 1800 may serve as a bridge between the distributed computing environment and the 

other environment Hie distributed computing environment may also provide a method or methods to wrap existing 

device discovery protocols for discovering the devices for access from the distributed network environment 

Bridging and wrapping protocols are fiirther described herein in the Bridging section. 

Control system 1800 may be comiected remotely or locally to one or more other systems in Ae distributed 
10 computing enviromnent Figure 40a shows control system 1800 comiected to client 1806 via fte Internet 180Z 

Client 1 806 may indirectly request the status ot and send control requests to, embedded 

through control system 1800. Urns, cont«,l system 1800 may serve as a pro^ or bridgp li,r embedded devices 
1804a and 1804b. See the Bridging section herein. To enable sophisticated communication between the cUent 1806 
and the control system 1800, the client and the control system may have different hnplementations of the XML 
15 messagmg system than the thin implementation on the embedded devices 1804a and 1804b. In one embodiment, 
client 1806 may include softwan: and hardware configoi^ to present an interfece to aHow a user of client 1806 to 
display the status of and remotely control the embedded devices 1804a and 1804b. In one embodiment, client 1806 
must present the correct authorization credentials to control system 1800 to enable the chent 1806 to access 
embedded devices ig04a and 1804b. In one embodiment, client 1806 may be granted access at different levels. For 
20 example, client 1806 may only be able to view the status of embedded devices 1804a and 1804b but not be allov^ed 
to remotely control the devices, one embodiment, control system 1800 may be a service, may have a s«v.ce 
advertisement published in the distributed computing enviromnent, and thus may be accessed by client 1 806 usmg 
the cUent-service method as descnT>ed previously in this document In one embodhnent, cUent 1806 ma^ 

viewthe status of, and to remotely control, control system 1800. 
25 Figure 40b illustrates cUent control system 1808 comiected via the Memet 1802 to embedded devices 

1804c and 1804d. according to one embodiment In one embodiment, embedded devices 1804c and 1804d may 
mclude a thin implementation of the XML messagmg system for commmricating vdth cUent control syst^ 1808 
over the totemet 1802. CUent control system 1808 may have an implementation of the XML messaging system for 
sending requests to and receiving responses fix,m embedded devices 1804c and 1804d. M 
30 controlsystemlSOSmayincludesoftwareandhardwareconfiguredtopresentaninterfecetoaUowaw 

Ae status of and remotely control the embedded devices 1804c and 1804d. In one embodiment, cUent control 
system 1800 may include software and/or hardware for automatic control of embedded devices 1804c^^^ 
A difference betweeii Figure 40a and Figure 40b is that, in the embodhnent inustraled in F^ 

embedded devices 1804c and 1804d may be accessed by one or moi« cUents in the distributed computing 
35 enviromnent without requiring a proxy (e.g. control ^). Embedded de^^ 

services for accessing the iimctionality of the devices, may have published service advertisements iuthe distributed 
computing environmeni, and thus may be accessed via the cUent-service method as descri^^ 

document. 

The distributed computing environment may include a mechanism for a resourco-limited cUent to retrieve 
40 Umversal Resource Identifier (URI) addressed r^omces. For example 
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receiying messages via an IrDA connection may not be able to establish a URI connection to retrieve results ftom a 
results space. In one embodiment, a service may be provided as a bridge between the client and the URI resource. 
The bridge service may interact with the client via XML messages to gather input parameters. Tlie following is 
included as an example of XML input message syntax and is not intended to be limiting in any way: 

<type name="HttpGer> 

<element name="nrlstringf ^e=^'strin^'A> 

Then, outside the distributed computing environment, the bridge service may establish a URI connection 
and retrieve the resoun:e. Tlie resource may then be encapsulated as a payload in one or more XML messages and 
sent to the client by the bridge service. 

•me followmg iUustration of one possible use of embedded devices wilh thin in^lementadons of the XML 
messaging system is mcluded for exemplaiy purposes and is not intended to be limiting. A building may mclude a 
pluraUty of electronic devices that consume energy (e.g. Ughts, air conditioneis. office equipment), and thus may 
require a system for maintaining an optimum energy consumption leveL The plurality of devices may each include 
an embedded device for controlling the electronic devices. The embedded devices include the ihin 
implementation of the XML messaging system. One or more control systems may be coupled to the devices in a 
network, for example, a building LAN or even the Internet. A control system may store and execute a building 
management software package and an implementation of the XML messaging system configured to be used by the 
0 software package for monitoring and controlling the devices. Hie control system may accept input from users, and 
may display and otherwise output status infprmatiott for the building energy consmnption system, including status 
mfonnation for each of the plurality of devices. Energy consumption may be monitored by receivmg XML status 
messages from eadi of the plurality of devices. When energy consumption levels need to be adjusted, XML control 
messages may be sent to one or more of the devices to cause the energy consumption to change. 

!5 

Implementing Services 

In one embodiment, the distributed computing environment may provide a mechanism for implementing 
services as servlets. The mechanism m^ provide functionality for developing services for the distributed 
computing environment 

30 IB one embodiment, an Application Programming Interfece (API) may be provided that provides the 

functionality to allow the service to be initialized and registered in a space. In one embodiment, the API m^ 
be used to invoke the initialization of the service and to generate an initialization status page, for example, an 
HTML page, that may define the status of die service. A user may access the status of the service by accessing the 
status page from a browser. In one embodiment, the API may be used to process incoming messages and to 

35 generate documents m response to the messages. 

An embodiment of the servlet mechanism may provide several functions including, but not limited to: 

• Management ofthe client connection to the service (unique session ID) 

• Management of an activation space that may be used to store results advertisements 

• Management of leases on connections sessions and results m activation spaces 
40 • Garbage collection of sessions and results 
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• Authentication of clients 

• Generation of client capabilities on a per session basis 

In one embodiment, tiie distributed computing environment may provide a service cascading mechamsm by which 
new, complex services may be constructed from other existmg services. For example, from a 3PEG-to-PostScript 
transformation service and a prmt service, combining the transfonnation and print service may create a third 
cascaded service. In one embodiment, two or more services may be combined into a complex service by defining 
access methods of the two or more services as the access methods of the cascaded service. The following service 
advertisement for a cascaded service is included for exemplary purposes 
and is not intended to be Ihniting in any way: 

<Service> 
<name>Complex Servicedname> 
<ID>„.</ID> 

<descriptioE^> .... </description> 

<AccessMethod> 

<;AccessMethod> 

<name>com.transcode. jpg2psdname> 

<implementation>http://vmw.transcodexom/software/jpg2psjardimplemente^^ 

</AccessMethod> 
<AccessMethod> 

<name>com.printer.ftpPrint</name> 

<implementation>http://AVWW.printerxom/sofhvare/flpprmLjar</m^^ 
</AccessMethod> 
</AccessMethod> 

</Service> 
Conclusioti 

Various embodiments may further include receiving, sendmg or stormg instructions and/or data 
implemented in accordance with the foregoing description upon a carrier medium. Generally speaking, a carrier 
medium may mclude storage media or memory media such as magnetic or optical media, e.g., disk or CD-ROM, 
volatile or non-volatile media such as RAM (e.g. SDRAH RDRAM, SRAM, etc.), ROM, etc. as weU as 
transmission media or signals such as electrical, electromagaetic, or digital signals, conveyed via a communication 
medium such as network and/or a wireless link. 

Various modifications and changes may be made as would be obvious to a person skilled in tiie art having 
the benefit of this disclosure. It is intended that the invention embraces aU such modifications and changes and, 

accordingly, die specifications, appendices and dmwmgs are to be regarded in an iUustrative rather than a restrictive 

sense. 
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WHAT IS CLAIMED IS: 

1. A method for accessing a services a dist^^utedcomputil^envff^ 

a client locatmg a first service within the distributed con]^uting environment; 
5 the cHent requesting a capability credential to allow the client access to a portion of the first service's 

capabilities, wherein said requesting a capability credential comprises the client indicating a set of 

desired capabilities; 
the cKent receiving said capabmty aetotial, A^erem said capability creden^^ 

the right to use said portion of the first service's capabilities; and 
10 the cUent using said capability credential to access one or more of said portion of the first service's 

capabilities. 

2 The method as recited in claim 1, wherein said requesting a capability credential comprises the cUent 
sending a capabiUty credential request message, wherein said capability credential request message comprises an 
15 identification ofsaid first service and an indication ofthe set of desired capabihties. 

3. the method as recited in claim 2, herein said identification of said first service comprises a Universal 
Unique Identifier GJUID). 

20 4. The method as recited in claim 2, wherein said capabiUty credential request message if formatted in 
extensible Martaip Language (XML). 

5 The method as recited in clahn 2, further comprising: 

the client receiving an advertisement for the first service, wherein said advertisement descn^^ 

25 of the first service's capabilities; and 

wherein said mdication of the set of desired capabiUties comprises an indication of said advertisement 



6. The 



method as recited in claim 5. wherein said indication of said advertisement is said advertisement itself. 



30 7. 



Tie method as recited in claim 5, wherem said indication of said advertisement is a Uniform Rcsonree 

Identifier (URl) to said advertisement 

8 Tie method as recited in claim 5, wherein said advertisement describes all of the first service's capabilities, 
and wherein sdd indication of said advertisement in said capabiUty credentid request message in 

35 advertisement edited to describe only said set of desired capabiUties. 

9 Tie method as recited in claim 5. wherein sdd advertisement is a protected advertisement th^ 
the first service's capabilities but does not provide an interfece to the first s^^^^ 
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10. The method as recited in claim 1, further comprising: 

the cUent receiving a protected advertisement for the j&rst service, wherein said protected advertisement 
mdicates an address for sending said capability credential request message to; and 

wherein said requesting a capability credential comprises the chent sending a capability credential request 
message to said address indicated in said protected advertisement 

11. The method as recited in claim 10, wherein said address mdicated m said protected advertisement is for an 
authentication service, wherein said sending a capability credential request message comprises sending said 
capabiUty credential request message to said autiientication service, tiie method further comprising the 
authentication service sending a credential request response message to the client in response to said capability 
credential request message. 

12. Hie method as recited in claim 11, wherein said credential request response message includes said 
capability credential, wherein smd receiving said capability credential comprises receiving said c^abiHty credential 
from said authentication service in said credential request response message. 

13. The method as recited in claim 1, fiirther comprising: 

tiie cUent receiving a protected advertisement for the first service, wherein said protected advertisement 

indicates an authentication service; and 
wherem said requesting a capability credential comprises tiie client requesting a capabiUty credential from 

said authentication service. 

14. The mettiod as recited in clahn 13, the method fiirther comprising: 

said authentication service determining a level of tiie firet service's capabitities that die chent is autiiorized 
to use; 

said autiientication service generating said capability credential according to said level and said set of 
desired c^abilities; and 

said autiientication service sendmg said capability credential to tiie client, wherein said portion of tiie first 
service's capabiUties tiiat said capability credential indicates tiiat tiie chent has a right to use is no 
more than said set of desired capabilities. 

15 The metiiod as recited in claim 14, wherem said portion of tiie first service's capabiUties tiiat said 
capabihty credential indicates tiiat flie client has a right to use is tiie lesser of said level of tiie first service's 
capabiUties tiiat tiie client is authorized to use and said set of desired capabiUties. 

16. The metiiod as recited m claim 1, wherein said usmg said capabili^ credential to access one or more of 
said portion of tiie first services capabiUties comprises tiie cUent sending a message to tiie first service to access a 
fiist capabiUty, wherem tiie message includes said capabihty credential, tiie mettiod fiirther comprising tiie first 
service autiienticating said capabiUty credential received in tiie message to verify tiiat tiie cUent has tiie right to use 
said first capability. 
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17. A client device, comprising: 

a comection to a distributed computing environment; 

an interface coupled to said connection and configured to locate a first service within the distributed 
computing environment; 

5 ^vherein the interface is fiirtber configured to request over the connection a capability credential for a set of 

desired capabilities to aUow the cUent on the cHent device access to a portion of the first service's 
capabilities; 

wherein the interface is fiirther configured to receive over the connection said capability credential, wherehx 
said capabiUty credential indicates that the cUent has the right to use said portion of the first 

IQ service's capabilities; and 

wherein tibe interfece is further configured to use said capability crede^^^ 

portion of the first service's C2^>abilities. 



25 



18. 



nie client device as recited m claim 17, wherem the mterfece is configured to request a c^abiUty 
15 credential by sendmg a capabiUly credential request message, wherein said capability credential request message 
comprises and identification of said first service and an indication of the set of desired capabilities. 

19. -Die chent device as recited m claim 18, wherein said identification of said first service comprises a 
Universal Unique Identifier (UUID). 

20 

20. The client device as recited in claim 18, wherein said capabihty credential request message if formatted in 
extensible Markup Language (XML). 

21. The Ghent device as recited in claim 18, v^^erein the interface is fiulher configured to receive an 
advertisement for the first service, wherein said advertisement describes the portion of tiie first service's capabilities, 
and wherein said mdication of tiie set of desired capabilities comprises an indication of said advertisement 

22. Tbe chent device as recited m claim 21, wherem said indication of said advertisement is said advertisement 
itself. 

23. The client device as recited m claim 22, wherem smd mdication of said advertisement is a Uniform 
Resource Identifier (URI) to said advertisement 

24. The client device as redted m claim 21, wherein said advertisement descn^esaU of 
35 capabihties, and wherein said mdication of said advertisement in said capability credential request message in a 

version of said advertisement edited to describe onty said set of desired capabihties. 

25. The cUent device as recited in claim 21, wherein said advertisement is a protected advertisement that 
describes the first service's capabilities but does not provide an interface to the first service's capabihties, 

40 
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26 Tteclientdevice as xecited inclato 17. wherein the interfece is fi^^^ 

advertisement for the first service. v,hereir. said protected advertisement indicates an address for sendmg sard 

capabmtycredentialrequestrnessage to, and wherein the interfece is configMred to requ^ 

sending a capability credential request message to said address indicated to said protected advertise^^^^ 

^ 27 The client device as redted in claiin 26, wherein said address indicated in said prote^^^ 
for an authentication service, wherein said sending a capabmty credential request me^^^ 
capability credential request message to said authentication service. 

10 28. mcKent device as recited m claim 27, wherein the interfece is configured to receive 
credential from said authentication service in a credential request response message, 

29 The cUent device as recited in claim 17. wherein the interfece is fiirther configure to: 

receive a protected advertisement for the first service, wherein said protected advertisement indicates an 
j5 authentication service; and 

request a capability credential by requesting a capability credential fiom said anflientication service. 

30 Tteclientdeviceasrecitedinclaim29,wheremsaidportionofthefirstservice'scapabilities1to^ 
capabitity credential indicates ftat the cUent has a ri#t to use is ti.e lesser of said level of the first s 

20 capabilities that the client is authorized to use and said set of desired capabilities. 

31 Tire cUent device as recited in claim 17. whereinthe interface is configured to use said capability credential 
to access one or more of said portion of the first services capabiUties for said cHent by sendmg a message to the first 
service to access a fir^ capability, wherein the message includes said capability credential so that the first servrce 

25 mayauthenticatesaidcapabiUtycredentialreceivedinthemessagetoverifythatthecUenthastherig^^ 

first capabiUty. 

32. THe cUent device as recited in claim 17. wherein said interfece comprises one ormore processes executable 
on a processor within the client device. 

33. A carrier medimn comprismg FOE-m instructi«is. wherein the program instructions a,* computer- 

executable on a client device to implement: 

locating a first service within the distnljuted computmg environs 

requesting a capabiHty ciedeutial to allow a client on the client device access to a portion of the first 
service's capabilities, wherem said requesting a capahiUty credential comprises the client 
indicatmg a set of desired capabiHties; 
receiving said capability credential, wherem said capability credential indicates that the client has the right 

to use said portion of the first service's capabilities and 
using said capabihty credential to access one or more of saidportion of 
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34 Tho carrier medium as recited in claim 33. therein said requesting a capability credential comprises the 
client sending a capability credential request message, wherein said capability credential request message comprises 
an identification of said first sendee and an indication of the set of desired w^^^ 

5 35; The carrier medium as recited in claun 34, wherein said identification of said first service comprises a 
UniversalUnique Identifier (UUID). • 

36. The carrier medimn as recited in clahn 34, wherein said capability credential request message if formatted 
in extensible Markup Language (XML). 



10 



37. The carrier 



15 



medium as recited in claim 34. wherein the program instructions are computer^xecutable on 

the client device to fiirther implement 

receivmg an advertisement for the first service, wherein said advertisement describes the portion of the first 

service's capabilities; and 
wherein said indication of the set of desired capabiUties comprises an indication of said advertisement 

ier medium as recited m claim 37, wherein said indication of said advertisement is said 



38. The carrier 
advertisement itself- 

20 39. n.e carrier tDedium as recited in claim 37. wherein said indication of said advertisement is a Uniform 
Resource Identifier (URI) to said advertisement 

40 nie earner medium as recited in claim 37, wherein said .advertisement describes all of the first service's 
capabilities, and wherein said indication of said advertisement in said capabflity credential request message in a 

25 version of said advertisement edited to describe only said set of desired capabilities. 

41 Ti,e carrier medium as recited in claim 37, wherem said advertisement is a protected advertisement that 
describes the first service's capabilities but does not provide an interfece to the first service's capabiUties. 

30 42. Hie carrier medium as recited in claim 33. wherein the program instructions are computer-executable on 
the client device to fiirther implement: 

receiving a protected advertisement for the first service, wherein said protected advertisement indicates an 

address for sending said capabiUty credential request message to; and 
wherein said requesting a capability credential comprises the client sending a capability credential request 
35 message to said address indicated in said protected advertisemeiit 

43 The carrier medium as recited m claim 42, wherein said address indicated m said protected advertisement 
fa for an authentication service. Wherein said sending a capabiUty credential ^ 



capabiUty credential request message to said airthentication service. 



40 
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44. me carrier medium as recited ib claim 43. therein said receiving said capability credential comprises 
receiving said capabiUly credential &om said authentication service in a credential request response message. 

45. The carrier medium as recited in claim 33, vvherein the program instmctions are computer-executable on 
the client device to tether implement: 

receiving a protected advertisement for the first service, wherein said protected advertisement indicates an 

authentication service; and 

wherein said requesting a capability credential comprises the client requesting a capability credential from 

said authentication service. 

46 Tbe carrier medium as recited in claim 45, whe«=in said portion of the first service's capabiHties that said 
capability credential indicates that fl« client has a right to use is *e lesser of said level of the fir:, service's 
capabiUties that the cUent is authoriwd to use and said set of desired capabilities. 

47 The carrier medium as recited in claim 33, wherein said using said capabiUty credential to access one or 
more of said portion of the first services capabilities comprises the client sending a message to the first service to 
access a first capabilily, wher^m the message includes said capability credential so that the first service may 
authenticate said capability credential received m the message to verify that the client has the right to use sard first 

capability. 
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